چرا سراغ جنگو رفتم

I Love Django

من فارغ‌اتحصیل برق الکترونیک هستم. قبلا با سی++، پرل و پایتون برنامه نوشته‌بودم. و مدتی هم در آزمایشگاه لایتک مشغول به کار بودم و کمی کد PHP نوشته‌بودم. دو مانع اصلی جلوی برنامه‌نویسی من را می‌گرفت. یکی دوباره‌کاری‌ها. برای هر فرم اطلاعاتی می‌باید جدول دیتابیس را می‌ساختیم، کدهای فرم‌ها را می‌نوشتیم که هر دو از نظر مفهوم بسیار به هم وابسته و شبیه هستند. مانع دوم من امنیت بود که کابوس هر لحظه من شده‌بود. حملات XSS، SQL Injection و حملاتی که هنوز نمی‌شناختم. ولی مهمترینش SQL Injection بود. این حفره به نفوذگر اجازه می‌دهد که از طریق ورودی خروجی‌های داده در وبسایت (و اپلیکیشن) به دیتابیس دسترسی پیدا کنه، و برای جلوگیری از آن اقدامات تکراری مختلفی باید انجام می‌شد که از حوصله من خارج بود. شاید به این دلیل که همیشه ممکن بود یکی از داده‌ها اشتباها فراموش شود و یک راه نفوذ ایجاد کند.

تا اینکه با جنگو آشنا شدم. جنگو برای هر نوع داده تنها به یک خط کد نیاز دارد. مثلا اگر داده‌ای از نوع عدد تعریف شود، در دیتابیس و فرم فیلترها و خطاهای لازم آن نوشته شده و روی داده اعمال می‌شود. همین‌طور برای هر جدول دیتابیس به سرعت می‌توان یک پنل ادمین ایجاد کرد. علاوه بر این همه داده‌ها از بابت نفوذ SQL Injection پالایش می‌شوند. و جالب‌تر اینکه هرزمان که به داده دیتابیس اشاره کنید، جنگو داده‌ای از همان‌نوعی که تعریف کردید در اختیارتان می‌گذارد و نیازی به تبدیل‌های اضافی ندارید.

معرفی جنگو

جنگو یک فریم‌ورک ساخت اپلیکیشن وب است. فریم‌ورکی به زبان پایتون. بر اساس گفته سایت جنگو و تجربه من، جنگو تا آنجا که ممکن است فرایند طراحی را سریع کرده.

جنگو یک ORM پیشرفته دارد.

با استفاده از ORM با استفاده از کدهای زبان مادری (مثلا در اینجا پایتون) به داده‌های دیتابیس دسترسی داریم و نیازی به نوشتن کدهای SQL نداریم. با این کار هم از روش‌های بهینه‌سازی ارتباط با دیتابیس استفاده می‌کنیم و هم نیازی به نوشتن کدهای SQL دشوار و تکراری و ادغام کدهای زبان مادری با SQL نداریم و هم برنامه ما در برابر SQL Injection ایمن می‌شود.

ORM جنگو به همین جا ختم نمی‌شود. اولا برای ساخت جدول‌های دیتابیس، برای هر ستون جدول یا به عبارت دیگر هر نوع داده مدل، تنها به یک خط کد پایتون ساده نیاز داریم. جنگو با سامانه Migration پیشرفته خود جدول‌ها را به صورت بسیار دقیق در دیتابیس می‌سازد. هر زمان که تغییری در نوع داده‌های خود دهیم، جنگو به پیشرفته‌ترین شکل ممکن داده‌های دیتابیس را مجدد متناظر با کد پایتون ویرایش می‌کند.

سیستم کوئری جنگو بسیار کامل است. به ندرت ممکن است نیازی به نوشتن کدهای SQL پیدا کنید. برای کوئری‌های پیچیده هم جنگو راه حل‌های بسیار ساده به زبان پایتون دارد. و با روش هوشمندانه خود، حتی توابع SQL به طور خودکار به کدهای پایتون تبدیل می‌شوند. یعنی حتی اگر تابعی را در دیتابیس تعریف کنیم، جنگو به طور خودکار، بدون تغییر در کدهای پایتون، به تابع دسترسی دارد.

روش Loosely Coupling در جنگو

جنگو به صورت ماژول‌ماژول طراحی شده. حتی ماژول‌هایی از آن را که به صورت پیش‌فرض هنگام ایجاد پروژه صدا می‌زند را می‌توانیم به سادگی از آن جدا کنیم و البته ماژول‌هایی را نیز در پروژه صدا نمی‌زند که هرگاه نیاز داریم به پروژه اضافه می‌کنیم. اما خاصیت Loosely Coupling بدین معنا است که روش کدنویسی که در مستندات جنگو آموزش داده می‌شود و خودش به درستی اجرا می‌کند، موجب می‌شود که برنامه‌نویسان، قسمت‌های مستقل کدشان را کاملا از پروژه خود مستقل کنند و به راحتی به یک بسته جدید جنگو در آورند. به همین دلیل بسته‌های پیشرفته بسیاری را در سایت رسمی بسته‌های جنگو می‌بینیم که قابل استفاده هستند. بر اساس این استاندارد، نصب این بسته‌ها تغییر اساسی در شیوه برنامه‌نویسی شما ایجاد نخواهند کرد. مثلا هر بسته مانند یک شارژر فندکی ماشین عمل می‌کنند. این شارژر تغییری در شیوه رانندگی شما ایجاد نمی‌کند، یا سیم‌کشی ماشین را به هم نمی‌زند و به صورت مستقل به شما کمک می‌کند.

معماری MVC (مدل، نما و کنترلگر)

معماری MVC هم یک نگاه طراحی است که ارتباط دیتابیس (مدل)، نما (ظاهر) و کنترل روند برنامه را از هم جدا می‌کند و با سه شیوه متفاوت به سراغ آن‌ها می‌رود.

مدل (Model)، یعنی همان ساختار شیٔ ما. مثلا شناسنامه یک شخص را در نظر بگیریم. ساختار اطلاعاتی آن (کد ملی، نام، نام پدر و مادر، نام فرزندان، نام همسر، تاریخ تولد) همان مدل را تشکیل می‌دهد. این که کد ملی از نوع عدد است و…

به محض نوشتن این مدل در جنگو، ساختاربندی دیتابیس آن(Migration)، با دو دستور به طور خودکار انجام می‌شود.

نما (View) در جنگو Template نام دارد. Template یک ادغام کدهای HTML (و یا هر نوع متن خروجی دیگر) با زبان Template جنگو است. استفاده از Template در پایتون یک اجبار است. چرا که پایتون قابلیت ادغام با فایل‌های HTML را مانند PHP ندارد. روش مرتب، استفاده از Template است. استفاده از Template همچنین نوشتن کدهای تکراری را به حداقل می‌رساند.

کنترل روند برنامه (Controller) در جنگو در فایل‌هایی به نام views.py نوشته می‌شود. این فایل‌ها عموما از توابع و یا کلاس‌هایی تشکیل شدند که اطلاعات درخواست ‌HTTP را به عنوان ورودی می‌گیرند، پردازش می‌کنند، اطلاعات مورد نیاز را از مدل دریافت می‌کنند (یا می‌نویسند) و با استفاده از ‌Template یک خروجی ساخته و به کاربر برمی‌گردانند. که این خروجی معمولا یک صفحه وب یا یک داده json یا یک فایل و… است.

مستندات جنگو

مستندات کامل جنگو حس قدرت را به من می‌دهد. برای هر قسمت از کدهای جنگو، مثال‌های کامل و متعددی در مستندات آن آورده شده که هم روش استفاده از آن و هم روش‌های استاندارد برنامه‌نویسی را از آن‌ها یاد می‌گیرم. همچنین کدهای جنگو به صورت جداگانه در مستندات آورده شده تا حتی بتوانید شیوه عملکرد هر قسمت از کد را متوجه شوید. دانستن شیوه عملکرد برای برنامه‌نویسان پیشرفته مهم است. این دانش، کارهای تکراری را کم و کمتر می‌کند.

حس خوب جنگو

از همه این‌ها که بگذرم، جنگو حس خوب برنامه‌نویسی وب را می‌دهد. معماری و روش‌های پیشبینی شده آن معمولا من را شگفت‌زده می‌کند. سامانه گزارش خطای جنگو، بسیار قدرتمند عمل می‌کند و برنامه‌نویسان علاقه‌مند جنگو، همواره هوشمندانه آماده همکاری در رفع خطاها هستند. سیستم پشتیبانی جنگو فرهنگ پیشرفته‌ای دارد. در لیست ایمیل آن (Mailing List) می‌توانید هر روز پرسش‌های جالب کاربران را مشاهده کنید و در آن‌ها مشارکت کنید. و همین‌طور در لیست ایمیل توسعه جنگو عضو شوید و در روند توسعه جنگو همکاری کنید.

فکر می‌کنم تا اینجا برای نوشتنم درباره کلیات جنگو کافی باشد. بسیار خوشحالم می‌کنید اگر نظرات ارزشمند خودتون رو (پرسش/پیشنهاد/انتقاد) در پایین این مقاله بنویسید.
در مقالات آینده در مورد روش توسعه در جنگو می‌نویسم.

تجربه‌ام با کتابراه

اولین باری که با کتابراه آشنا شدم را به خاطر نمی‌آورم. نمی‌دانم چرا اولین بار کتابراه را نصب کردم. اما به یاد دارم که تخفیف اولیه پنجاه درصدی آن (welcome50) خیلی به من چسبید.

تعداد کتاب‌های کتابراه به نظر زیاد نمی‌آمد، اما محیط کار جذاب‌تری به نسبت فیدیبو برایم داشت. به نظر من کتابراه محیط مشخص‌تری داشت. روی دکمه‌ها و اینکه آیا باید وجود داشته‌باشند یا نه و چه شکلی باشند بهتر کار شده‌بود. یادم می‌آید که همان‌زمان درباره این تجربه محیط کتابراه با دوستانم صحبت کردم و به نظر می‌رسید که آن‌ها این موارد را متوجه نمی‌شدند.

نکته جالبی که برایم داشت این بود که کتابراه روی تعداد کتاب‌هایش مانور نمی‌داد یا دست‌کم من تبلیغی در این باره نمی‌دیدم. من از این تبلیغ نکردن و تجربه کاربری پیشرفته کتابراه، این برداشت را کردم که کتابراه به هر دلیل بیشتر روی کیفیت مانور می‌دهد تا کمیت.

سئو (خوانایی سایت برای گوگل)

از سئوی کتابراه خوشحالم. به نظر می‌رسد که روش و سیاست‌های وب کتابراه به خوبی گوگل را مجاب کرده که کتابراه در نتایج بالای جستجو به نمایش در آیند. و سیاست‌های کتابراه به خوبی کاربران را به خود جذب کرده.

نگاهی به روند پیشرفت بازدید کتابراه در Alexa رشد کتابراه را نمایش می‌دهد
رتبه ۲۹۴ در ایران بر اساس اطلاعات Alexa به نظر من رتبه جذابی است. و در کنار آن کاربران همسایه و همزبان افغان ما نیز استفاده خوبی از این وبسایت دارند.

رتبه کمتر از ۳۰۰ کتابراه در مقایسه با فیدیبو با رتبه بیش از ۴۰۰ در ایران، با وجود تبلیغات دیجیکالا، نشانگر سیاست‌ها و تیم قدرتمند کتابراه است. این به معنی یک قدرت پایدار در کتابراه است. مانند یک مغناطیس مانا در هسته آهنی. در حالی که فیدیبو به نظر یک قدرت مغناطیس در هسته غیرآهنی است. یعنی با تغییر سیاست‌های دیجیکالا و حذف پشتیبانی آن، احتمال ضعف فیدیبو در مقابل کتابراه وجود دارد.

پشتیبانی کتابراه

تا پیش از بهمن ۱۳۹۷ (آغاز سال ۲۰۱۹) این امکان وجود داشت که مستقیم به پشتیبانی کتابراه از داخل اپلیکیشن پیام بدهیم. همین موضوع موجب شد که چندین باگ از کتابراه را به ایشان گزارش دهم. و خوشبختانه کتابراه این مشکلات را حل کردند. از جمله:

  • افزودن قفسه به کتابخانه من و کاهش تعداد کتاب‌های نمایشی در کتابخانه من
  • بهبود سرعت صفحه اصلی برای گوشی‌های کندتر، که به سرعت رفع شد
  • امکان اشتراک‌گذاری صفحه‌های کتاب
  • مشکل اسکرول اشتباه کتاب‌های PDF

این موارد سریع برطرف شدند. البته مواردی هم بودند که برطرف نشدند. اما دست‌کم پاسخ ایمیل به این صورت آمد که «برای بررسی به تیم فنی ارسال شد»

انتقاد از پشتیبانی

اما از تقریبا ۲ ماه قبل (بهمن ۱۳۹۷) کتابراه هم قسمت ارسال نظرات پشتیبانی را از اپلیکیشن برداشت و به سایت منتقل کرد و هم برخورد بسیار تندی هنگام دریافت پشتیبانی پیدا کرد. من یک باگ هنگام خرید کتاب پیدا کردم که ممکن بود برخی کاربران خاص را از خرید کتاب منصرف کند، اما پشتیبانی به گونه‌ای برخورد کرد که انگار من صاحب کتابراه هستم و ایشان مجری برنامه‌نویسی و در حال دفاع از کدهای خود است.

با عرض سلام و وقت بخیر

دوست عزیز تمامی موارد اشاره شده در حال حاضر در نرم‌افزار کتابراه ارایه شده است.
در صفحه نظرات کتاب همانطور که خودتان اشاره نمودید، با زدن بر روی جلد کتاب، به بخش معرفی کتاب هدایت می‌شوید.

پاسخ کتابراه یه یک انتقاد که کاربر را در زمان لازم به سمت خرید ارجاع نمی‌داد. یعنی هنگام کلیک روی عکس کتاب کاربر به صفحه‌ای که منجر به خرید شود منتقل نمی‌شد

به نظر من این خود یک خطر بزرگ برای هر نوع نرم‌افزاری است که اولا به نظر می‌رسد تیم برنامه‌نویسی از تصمیم‌گیرندگان اثر شاکی هستند. یعنی تصمیم‌گیرندگان نتوانستند شادی مورد نیاز را به تیم برنامه‌نویسی برسانند. و از طرف دیگر تیم پشتیبانی در حال طرفداری اشتباه از تیم برنامه‌نویسی است. این خود یک مثلث نکبت است که:

  • تیم برنامه‌نویسی نقش قربانی
  • تیم پشتیبانی نقش ناجی
  • و من مشتری شاید در نقش چالشگر یا شاید هم سرزنشگر است.

شاید این اتفاق به علت تغییر چینش کارمندان کتابراه اتفاق افتاده. ولی یک نکته مهم به نظر من در هر گونه پشتیبانی وجود دارد. اینکه بررسی کنیم:

  • آیا تیم پشتیبانی در حال صحبت با درخواست کننده است یا در حال بستن موضوع.
  • آیا در صورت انتقاد پشتیبانی از کاربر به ایشان راه حل جایگزین درست داده شده یا نه؟
  • آیا قوانین و کمک‌های مورد نیاز کاربر به صورت دقیق ارسال شده یا به صورت کلی پیوند یا ارجاعی به قوانین و مستندات داده شده؟

مثلا تیم پشتیبانی در پاسخ به من لینک help کتابراه را ارسال کردند که مفهوم خاصی را نداشت. به یاد دارم دقیقا در ویکیپدیا نیز چنین اتفاقی افتاد و مقاله‌ای که نوشتم را حذف کردند، و لینک به دلایل حذف مقاله ارسال کردند.

با سلام و وقت بخیر
کاربر گرامی لطفا پیشنهادات خود را در بخش نظرات کتاب ارسال ننمایید.

http://ketabrah.ir/page/help

پاسخ کتابراه به یک کامنت پس از حذف آن، هنگامی که متوجه شدم کتابراه روش ساده‌ای برای پشتیبانی ندارد، در کامنت یکی از کتابها انتقادم به کتابراه را مطرح کردم. تیم کتابراه بهتر است پیوندی به صفحه پشتیبانی ارسال کنند و نه یک مطلب خواندنی. آن هم به صورت کلی (صفحه help).

پس به نظر من باید وظیفه پشتیبانی این باشد که دقیقا به خطی که در حال پاسخگویی به کاربر است اشاره کند. این برای آگاهی تیم پشتیبانی واجب است. مثلا در ویکیپدیا (لینک دلایل حذف پرونده ارسال شد) که در حقیقت یک لینک کلی است. به هرحال شاید یکی از دلایل حذف پرونده وجود داشته‌است. مانند آن است که خانه‌ای را خراب کنیم و در پاسخ صاحب‌خانه بگوییم به کتاب قانون اساسی کشور مراجعه کنید. یا مسیری را مسدود کنیم و ارجاع دهیم به کتاب قانون اساسی کشور. روش درست، ارجاع به خطی که این مورد را نوشته، و به دستوراتی که داده شده است.

نکته منفی دیگری هم در پشتیبانی کتابراه و سایت وبسایت‌ها و اپلیکیشن‌ها دیدم. که رفع آن کار دشوار و در عین حال مفیدی است. این که با وجود تغییرات جذاب کتابراه با پیام‌های من به پشتیبانی، و قطعا سایر کاربران علاقه‌مند، اپلیکیشن‌ها از جمله کتابراه هیچ گونه سپاسگزاری از کاربر نمی‌کنند، در صورتی که رفع و بهبود این موارد، کمک چشمگیری در رشد آن‌ها دارد. این مورد را در بسیاری جاها که کار کردم اتفاق افتاد که این تغییرات ارزشمند را به خوبی نادیده می‌گیریم. با تصور اینکه کمک‌کننده متوجه ارزش ارائه داده شده خود نیست و بهتر است که ما نیز بازگو نکنیم تا نیازی به دادن پاداش نباشد. حال آنکه کمک‌کننده به زودی متوجه این ارزش ارائه داده شده خود می‌شود.

شاید بهتر باشد در سیاست پشتیبانی خود، پاداش به پرسشگر و انتقادگر را جزء مهم کار خود به حساب آوریم.

جمع‌بندی

هرچند این موارد، گروهی از مخاطبان اپلیکیشن را آزرده می‌کند. اما جمعیت بزرگی از اپلیکیشن، حتی متوجه حذف پشتیبانی، و متوجه مشکلات اپلیکیشن نمی‌شوند. تغییر سیاست‌های کتابراه، موجب رشد چشمگیر اپلیکیشن با توجه به گزارش Alexa شده، که به نظر می‌رسد این تغییر تیم پشتیبانی، یا اثر ریزشی روی مخاطبان نداشته و یا اهمیت آن در این دوره کتابراه چشمگیر نبوده.

با وجود دلزدگی از کتابراه فعلا اپلیکیشن بهتری برای جایگزینی کتابراه پیدا نکردم که مسیر حرکتی به جذابیت کتابراه داشته‌باشد. هرچند انتقاد تند کتابراه می‌تواند موجب جدایی خودم از کتابراه شود. با وجود خریدهای بسیار از آن.