برنامه نویسی - هیوادار

استفاده بد از تکنولوژی

گاهی پیش میاد که توی کدهایی که میخونم از برنامه نویسهای دیگه مشکلات زیر رو توشون میبینم:

1.از یک Framework استفاده شده ولی از تمامی قابلیتهاش استفاده نشده و گاهی میبینیم قابلیتی که توی فریمورک به خوبی و استاندارد پیاده سازی شده رو استفاده نکرده و خود شخص اون قابلیت رو کد زده

2.کتابخانه یا فریمورکی نصب شده و قابلیتی داره ولی از اون استفاده نشده و برای اون قابلیت کتابخانه دیگری نصب شده

دلیل این اشتباه اینه که برنامه نویس مستندات اون فریمورک و کتابخانه رو نخونده. کد زیر مثالی از حالت اوله. ببینید در ادامه یک فرم جنگو Django میبینیم:

class ServiceForm(ModelForm):
    def __init__(self, *args, **kwargs):
        super(ServiceFormPart3, self).__init__(*args, **kwargs)
        self.fields['service_account'].empty_label = ' '
        self.fields['technician'].empty_label = ' '
        self.fields['service_manager'].empty_label = ' '
        

    class Meta:
        model = Service
        fields = [
            "service_account", "technician", "service_manager"...
        ]

class ServiceForm(ModelForm):

def __init__(self, *args, **kwargs):

super(ServiceFormPart3, self).__init__(*args, **kwargs)

self.fields['service_account'].empty_label = ' '

self.fields['technician'].empty_label = ' '

self.fields['service_manager'].empty_label = ' '

class Meta:

model = Service

fields = [

"service_account", "technician", "service_manager"...

]

و کد زیر view هست که توی اون از این فرم استفاده شده:

def service(request, service_id):
    svc = Service.objects.get(pk=service_id)
    update_versions(svc)
    context = {
        'id': service_id,
        'service': svc,
        'form1': ServiceForm(instance=svc),
    }
    if request.method == "POST":
        name = request.POST.get("name", None)
        if not name:
            messages.error(request, '...', extra_tags='danger')
            return redirect(f'/man/service/{service_id}/')
        branch = request.POST.get("branch", None)
        if not branch:
            messages.error(request, 'ا...', extra_tags='danger')
            return redirect(f'/man/service/{service_id}/')
        office = request.POST.get("office", None)
        if service_account == '':
            service_account = None
        technician = request.POST.get("technician", None)
        if technician == '':
            technician = None
        service_manager = request.POST.get("service_manager", None)
        if service_manager == '':
            service_manager = None
        

        svc.service_account_id = service_account
        svc.technician_id = technician
        svc.service_manager_id = service_manager
        svc.save()
        messages.success(request, 'اطلاعات سرویس با موفقیت به روز شد')
        messages.info(request, json.dumps({
            'service_id': f'service_{service_id}',
        }))
        return redirect(f'/man/service/')
    else:
        return render(request, "man/service/service.html", context)

def service(request, service_id):

svc = Service.objects.get(pk=service_id)

update_versions(svc)

context = {

'id': service_id,

'service': svc,

'form1': ServiceForm(instance=svc),

}

if request.method == "POST":

name = request.POST.get("name", None)

if not name:

messages.error(request, '...', extra_tags='danger')

return redirect(f'/man/service/{service_id}/')

branch = request.POST.get("branch", None)

if not branch:

messages.error(request, 'ا...', extra_tags='danger')

return redirect(f'/man/service/{service_id}/')

office = request.POST.get("office", None)

if service_account == '':

service_account = None

technician = request.POST.get("technician", None)

if technician == '':

technician = None

service_manager = request.POST.get("service_manager", None)

if service_manager == '':

service_manager = None

svc.service_account_id = service_account

svc.technician_id = technician

svc.service_manager_id = service_manager

svc.save()

messages.success(request, 'اطلاعات سرویس با موفقیت به روز شد')

messages.info(request, json.dumps({

'service_id': f'service_{service_id}',

}))

return redirect(f'/man/service/')

else:

return render(request, "man/service/service.html", context)

مشکل کجاست؟ برنامه نویس اومده مقدار فیلدهایی که از template ارسال شده POST با استفاده از request.POST.get گرفته شده. بعد برنامه نویس اومده field validation (اعتبارسنجی فیلدها) رو انجام داده. بعد اگر توی ورودی فیلد ایرادی وجود داشت اومده یک پیام ارور به کاربر نشون داده. تمامی این کاری که برنامه نویس براش کد زده توی django.forms.Formپیاده سازی شده. به بهترین شکل توی جنگو پیاده سازی شده. در حالی که با تست این view مشکلات خیلی زیادی هست.

با استفاده از ServiceForm.is_valid() تمامی فیلدها validate و اعتبار سنجی میشن و اگر ایرادی داشته باشه همونجا فیلد قرمز رنگ میشه و ارور مرتبط نشان داده میشه اما در این حالت اگر یک فیلد required توی فرم خالی بمونه ارور مرتبط به کاربر نشان داده نمیشه. مشکل دوم اینه که مثلا اگر یک فیلد ایمیل یا پسورد باشه ایمیل با روش های استاندارد اعتبارسنجی میشه و پسورد هم همینطور.

مشکل بعدی این کد اینه که کد کثیفه و از طرفی همین الان ممکنه چنتا باگ داشته باشه که با ورودی های مختلف خودشو نشون میده و ما الان نمیدونیم وجود داره یا نه.

همینطور که توی این لینک میبینید فرم جنگو چند لایه صحت سنجی داره.

همیشه اگر از فریمورک یا کتابخانه ای استفاده میکنید حتما تمامی مستنداتش رو بخونید.

درگیری جدید با django-ckeditor-5

برای اضافه کردن فونت به CKEditor توی Django راه حل طبق این لینکه. منتها مساله اینه که من با نصب ورژن 5 نمیتونستم این مدلی فونت اضافه کنم.

توی django_ckeditor_5 تنظیمات فونت توی django_ckeditor_5/dist/bundle/js اضافه میشه. البته فقط تنظیمات فونت اینجوریه.

بخاطر همین فایل bundle.js رو prettify کردم و فونت ها رو سرچ کردم و Bnazanin رو بهش اضافه کردم مثل کد زیر

.
.
.
class Ov extends Xs {
            static get pluginName() {
                return "FontFamilyEditing"
            }
            constructor(e) {
                super(e), e.config.define(Av, {
                    options: ["default", "Bnazanin", "Arial, Helvetica, sans-serif", "Courier New, Courier, monospace", "Georgia, serif", "Lucida Sans Unicode, Lucida Grande, sans-serif", "Tahoma, Geneva, sans-serif", "Times New Roman, Times, serif", "Trebuchet MS, Helvetica, sans-serif", "Verdana, Geneva, sans-serif"],
                    supportAllValues: !1
                })
            }
            init() {
.
.
.

class Ov extends Xs {

static get pluginName() {

return "FontFamilyEditing"

}

constructor(e) {

super(e), e.config.define(Av, {

options: ["default", "Bnazanin", "Arial, Helvetica, sans-serif", "Courier New, Courier, monospace", "Georgia, serif", "Lucida Sans Unicode, Lucida Grande, sans-serif", "Tahoma, Geneva, sans-serif", "Times New Roman, Times, serif", "Trebuchet MS, Helvetica, sans-serif", "Verdana, Geneva, sans-serif"],

supportAllValues: !1

})

}

init() {

و یه فایل ساختم توی django_ckeditor_5/css/font.css و کد زیر رو زدم:

@font-face {
  font-family: "Bnazanin";
  src:
    url("../farsifonts/B-NAZANIN.TTF"),
  font-weight: normal;
  font-style: normal;
}

@font-face {

font-family: "Bnazanin";

src:

url("../farsifonts/B-NAZANIN.TTF"),

font-weight: normal;

font-style: normal;

}

و البته دایرکتوری django_ckeditor_5/farsifonts/ رو ساختم و فایل ttf فونت رو کپی کردم توش.

و تمام

راه حل غیر استاندارده چون هر بار اگر بخام تغییر بدم باید bundle.js رو تغییر بدم درستش این بود که ورژن جدید CKEditor رو نصب کنم. ولی امکانش نبود.

تجربه جالب اختلال اتصال به ریپوزیتوی داخلی

پروژه ای رو توی یه سرور Redhat 8 دیپلوی کردیم و از اونجای که سرور لینک اینترنت نداشت و سرویس داخلی شبکه شرکت بود هیچ پکیجی رو نمیشد از repository های استاندارد Redhat نصب و آپدیت کرد.

پروژه رو داکرایز Dockerize کردیم و عملا یه شبکه و چند تا اینترفیس به Interface های لینوکس اضافه شد.

از شرکت یه repository لوکال گرفتیم چون چاره ای نبود. Nexus نصب کرده بودن و پکیج ها هم آپدیت بود. لینک هاشو گرفتم و ست کردیم روی ردهت ولی آپدیت نمیشد و destination unreachable میداد هر دو توی شبکه داخلی و آی پی سرور از رنج 10.x.y.z و رنج آی پی ریپو 172.17.x.y هست telnet نداره و traceroute ( که توی ردهت tracepath هست و traceroute رو حذف کردن) نشون میده که پکتها توی خود سرور drop میشه.

اول فکر کردم که route ای وجود نداره ولی بعد از troubleshooting یه نکته جالب دیدم.

Docker به صورت پیشفرض یه اینترفیس مجازی به اسم docker0 میسازه که آی پی پیشفرضش تو رنج 171.17.x.y هست و به صورت اتفاقی توی رنج Nexus بود بنابراین پکتهای درخواست از ریپو به داکر ارسال میشه و چنتا کانتینر container ما هم پکت رو طبیعتا drop میکردن.

کانتینرها رو پایین آوردم

docker compose down

1	docker compose down

docker0 رو حذف کردم

ip link del docker0

1	ip link del docker0

و آپدیت درست شد Yum update

استفاده از CKEditor توی پروژه (جنگو)

اگر توی جنگو نیاز دارید که به جای یک Text Area خشک و بی روح یک ادیتور کامل داشته باشید (مثلا برای نوشتن بلاگ که به بولت چونت و هایلایت و …. نیاز دارید) میتونید از django-ckeditor-5 استفاده کنید. مستندات خود کتابخونه کامل نحوه نصب و تنظیمات رو گفته و نیازی به توضیح دادن کدش نیست. من قسمت هایی که برای جالب بود رو میگم:

یه کتابخونه کامله که بعد از نصبش و migrate کردن دیتابیس میتونید از فیلدهای جدیدی که اضافه میکنه توی ORM استفاده کنید مثلا به جای استفاده از فیلدهای استاندارد جنگو میشه از CKEditor5Field استفاده کرد

from django_ckeditor_5.fields import CKEditor5Field

1	from django_ckeditor_5.fields import CKEditor5Field

لازم نیست توی template کاری بکنید چون خود فایلهای استاتیک رو اضافه میکنه و اتوماتیک رندر میکنه.

توی تعریف فرمها میشه از widget هایی که اضافه کرده استفاده کرد. ولی یه بخشی که برای من خیلی جالب بود اینه که من نیاز داشتم از اون فرمهای رندر شده گاهی یه درخواست AJAX به یک route بفرستم و متوجه شدم مثل حالت معمولی نمیشه دیتای textarea رو با JQuery بگیرم و ازش توی request استفاده کنم. گشتم و متوجه شدم که توی تمپلیت ادیتور قابل دسترسی هست و از API هاش میتونم استفاده کنم. مثل کد زیر از editors لیست فیلدهایی که ckeditor بودن رو داشته باشم و با تابع getData() دیتای رندر شده شو بگیرم یعنی دیتایی که فرمت HTML داره و باید توی دیتابیس ذخیره بشه.

<script>

        function feedback_online(){
            var dataString = {
                'platform_awareness': $('#id_platform_awareness').val(),
                'main_points': editors[0].getData(),
                'secondary_points': editors[1].getData(),
                'guids_and_recommendations': editors[2].getData()
            }
            $.ajax({
                type: "POST",
                url: "/man/documents/feedback/ajax/{{id}}/",
                data: dataString,
                success: function(data) {
                    alert(data);
                }
             });
             return false;
        }
    </script>

function feedback_online(){

var dataString = {

'platform_awareness': $('#id_platform_awareness').val(),

'main_points': editors[0].getData(),

'secondary_points': editors[1].getData(),

'guids_and_recommendations': editors[2].getData()

}

$.ajax({

type: "POST",

url: "/man/documents/feedback/ajax/{{id}}/",

data: dataString,

success: function(data) {

alert(data);

}

});

return false;

}

</script>

مشکل کندی در اپلیکیشن

اخیرا یک پروژه با بک اند Django رو review کردیم که مشکل کندی داشت، کارفرما دسترسی به سرور رو نداد و قرار شد توی کد ببینیم مشکل از کجاست.

به خوبی از امکانات جنگو استفاده شده بود، از کتابخانه خارجی بی مورد استفاده نشده بود و از ماژولهای داخلی جنگو استفاده شده بود. ساختار پروژه استاندارد بود و تغییرات من در آوردی (به اسم خلاقیت) نداشت و توسعه دهنده کاملا طبق مستندات رسمی جلو رفته. Model ها روابط پیچیده نداشتند، به بهترین شکل از ORM پیشفرض جنگو استفاده شده بود، مشکلی توی query هایی که توی View ها زده بود دیده نمی شد (مشکل n+1 رو توی دسترسی ها به دیتابیس رو بررسی کردیم، Query تکراری نداشت ) و …

Docker رو تست کردیم کانشکن بین container ها کند نبود، منابع کم نبود.

در نهایت به سرور دیتابیس و production سری زدیم، کاری که از اول باید میکردیم. توی dockerfile خود اپلیکیشن دیدیم اون رو با runserver اجرا کرده که طبیعیه که سرعت خیلی پایین باشه چون این صرفا برای توسعه و تست هست نه production. با Gunicorn دیپلوی کردیم و مشکل کندی حل شد.

Gunicorn پردازش concurrent رو میده و میشه بهش بگی روی چند تا worker اجرا بشه. Scalable هست و یه سری قابلیت دیگه که برای محیط عملیاتی نیازه مثل مدیریت لاگ و ارورها و …

ریزکاریهای تست جنگو با TransactionTestCase و TestCase

در پست قبل دیدیم که برای نوشتن تست در جنگو میتونیم از کلاس های django.test.TestCase و django.test.TransactionTestCase استفاده کرد (البته که از خود unittest پایتون هم می توان استفاده کرد اما این کار در جنگو منطقی نیست چرا که کلاسهای تعریف شده برای تست در جنگو قابلیت های زیادی برای تست اضافه کرده اضافه کرده. مثلا اگر با unittest پایتون استاندارد بخاید تستی بنویسید که نیاز به دسترسی دیتابیس یا اجرا اپلیکیشن وب داشته باشد قطعا به مشکل میخورید بنابراین هیچ کس این کار رو نمیکنه). دیدیم که یک کلاس دیگه به اسم django.test.LiveTestCase هم وجود داره که میتونید توی اون از کلاینت Selenium استفاده کنید که تست های لایو توی مرورگر رو داشته باشید.

سوالی که پیش میاد اینه که فرق TestCase و TransactionTestCase چیه؟ توی خود کد جنگو نوشته:

class TestCase(TransactionTestCase):
    """
    Similar to TransactionTestCase, but use `transaction.atomic()` to achieve
    test isolation.

    In most situations, TestCase should be preferred to TransactionTestCase as
    it allows faster execution. However, there are some situations where using
    TransactionTestCase might be necessary (e.g. testing some transactional
    behavior).

    On database backends with no transaction support, TestCase behaves as
    TransactionTestCase.
    """

class TestCase(TransactionTestCase):

"""

Similar to TransactionTestCase, but use `transaction.atomic()` to achieve

test isolation.

In most situations, TestCase should be preferred to TransactionTestCase as

it allows faster execution. However, there are some situations where using

TransactionTestCase might be necessary (e.g. testing some transactional

behavior).

On database backends with no transaction support, TestCase behaves as

TransactionTestCase.

"""

میگه هردو مثلا همه و توی بیشتر شرایط باید TestCase رو ترجیح بدید چون سریع تره مگر در شرایطی خاص باید TransactionTestCase رو استفاده کنید مثلا اونجا که تستی که مینویسید تراکنش به دیتابیس داره و باید انجام بشه. میگه توی دیتابیسی که از تراکنش پشتیبانی نمیکنه عملا هر دو یکی هستن مثلا دیتابیس MySQL با موتور MyISAM.

توی مستندات جنگو گفته که TransactionTestCase از SimpleTestCase ارثبری کرده و چنتا قابلیت استفاده کرده. مثلا دیتابیس رو بعد از هر متد تست به حالت تعریف شده بر میگردونه که این توی تست مهمه مثلا 100 تا تابع تست داریم باید بعد از هر کدوم دیتابیس ریست بشه که روی تست های دیگه تاثیر نذاره. TransactionTestCase اطلاعات رو ممکنه commit و rollback کنه و بعد از هر تست هم حتما دیتابیس رو truncate میکنه اما TestCase برای سرعت بیشتر truncate نداره و از تراکنش ها استفاده میکنه یعنی rollback میکنه. این کار باعث میشه توی تستهای که نیاز به تراکنش هست به مشکل بخورید مثلا select_for_update ها.

در کل چیزی که من تجربه کردم اگر توی توابع تست یک کلاس تستکیس، update یا insert دیتابیس دارید از TransactionTestCase استفاده کنید. اگر فقط select دارید از TestCase استفاده کنید که سرعت بیشتری داره. اگر کلا با دیتابیس کاری ندارید از SimpleTestCase استفاده کنید.

سوال مصاحبه

در ادامه یک سوال مصاحبه جالب از یک شرکت غیرایرانی رو میبینیم که زمان انجامش 45 دقیقه است.

کد زیر را کامل کنید. هدف این است که یک XML به صورت تکست به شما بدهند و شما یک object برگردانید که المانهای این XML در آن قابل فراخوانی باشند همانطور که در تابع main میبینید. (کد به صورت بازگشتی باشد)

if __name__ == "__main__":
    xml_ = "<?xml version='1.0'?><State><City><Name>NewYork</Name></City></State>"
    root = ET.fromstring(xml_)

    r = MyXML(root)
    res = xml_to_obj(root, r)

    city = getattr(r, 'City')
    print(city)
    name = getattr(city, "Name")
    print(name)
    text = getattr(name, "Name")
    print(text)

if __name__ == "__main__":

xml_ = "<?xml version='1.0'?><State><City><Name>NewYork</Name></City></State>"

root = ET.fromstring(xml_)

r = MyXML(root)

res = xml_to_obj(root, r)

city = getattr(r, 'City')

print(city)

name = getattr(city, "Name")

print(name)

text = getattr(name, "Name")

print(text)

سیستم اعتبارسنجی جنگو

دانستن شمای کلی سیستم اعتبارسنجی جنگو authentication system دید خوبی در شروع هر پروژه ای به توسعه دهنده ها میده:

کار کردن بهینه با دیتابیس جنگو

راه های بهینه استفاده کردن دیتابیس:

1.توی query هایی که با استفاده از ORM بر روی دیتابیس اجرا میکنیم بهتر است خود SQL آن را ببینیم با استفاده از پرینت کردن query

2.از Indexing در ORM استفاده کنیم

3.وضعیت بهینگی query ها را ببینیم با استفاده از ابزارهایی مثل django-debug-tools

4.مراقب مشکلاتی مثل N+1 problems باشیم

5.از caching استفاده کنیم

6. از قابلیت query laziness در QuerySet های Django نهایت استفاده را بکنیم

7.Query تکراری اجرا نکنیم

8.QuerySet.explain() بهینگی و زمان اجرا query را به من نشان می دهد

9.به حداقل رساندن DB hit با استفاده از prefetch_related و select_related

در لینک زیر مثالهایی از اجرای query اضافی در دیتابیس میبینیم

https://docs.djangoproject.com/en/4.2/topics/db/optimization/

کاربرد nested method در پایتون

کد زیر رو می تونید توی django.forms.fields.py ببینید. یه نکته جالب داره. متد split_url رو توی متد to_python تعریف کرده:

class URLField(CharField):
    widget = URLInput
    default_error_messages = {
        "invalid": _("Enter a valid URL."),
    }
    default_validators = &#91;validators.URLValidator()]

    def __init__(self, **kwargs):
        super().__init__(strip=True, **kwargs)

    def to_python(self, value):
        def split_url(url):
            """
            Return a list of url parts via urlparse.urlsplit(), or raise
            ValidationError for some malformed URLs.
            """
            try:
                return list(urlsplit(url))
            except ValueError:
                # urlparse.urlsplit can raise a ValueError with some
                # misformatted URLs.
                raise ValidationError(self.error_messages&#91;"invalid"], code="invalid")

class URLField(CharField):

widget = URLInput

default_error_messages = {

"invalid": _("Enter a valid URL."),

}

default_validators = [validators.URLValidator()]

def __init__(self, **kwargs):

super().__init__(strip=True, **kwargs)

def to_python(self, value):

def split_url(url):

"""

Return a list of url parts via urlparse.urlsplit(), or raise

ValidationError for some malformed URLs.

"""

try:

return list(urlsplit(url))

except ValueError:

# urlparse.urlsplit can raise a ValueError with some

# misformatted URLs.

raise ValidationError(self.error_messages["invalid"], code="invalid")

سوال اینجاست که چرا باید یه متد رو توی متدی دیگه تعریف کرد؟ کاربردش چیه؟ مزایاش چیه؟ و چجوری باید صدا زد اونها رو:

دلیل استفاده از این روش توی OOP گفته شده که اگر قرار باشه که یک کار رو چندین بار توی یک متد انجام داد باید اون رو یک به صورت یک تابع بنویسیم تا اینجا که واضحه (دلیل تابع). حالا فرض کنیم بخایم از یک تابع فقط توی یک متد از یک کلاس استفاده کنیم، یعنی اصلا حتی به متدهای دیگه همون کلاس ربطی نداره. اون وقته که منطقی میشه از این روش استفاده کرد و فقط هم باید توی همون متد to_python صدا زده بشه.

مزایاش که مشخصه، اگه کدی لازم نباشه به scope های دیگه نشون داده نمیشه و مزایای دیگه…