do it on the web

خب از اون جایی که “همه چیزمان باید به همه چیزمان بیاید” بعید نمی دیدم که نمایشگاه دیجیتال و سیستم های چند رسانه ای (مالتی مدیا) ایران بیشتر درگیر مسایل دینی و دفاع مقدس باشد تا تولیدات واقعی ولی به هیچ وجه فکر نمی کردم که تا این حد درگیر باشد!

دو روز پیش در حالی به نمایشگاه واقع در مصلی تهران رفتم که فکر می کردم باید حداقل دو یا سه ساعت از وقتم رو برای این کار کنار بگذارم پس بعد از اتمام کارم در “پارس پیک” با چند نفر از همکاران که اتفاقا جزو کار درست های عرصه ی مالتی مدیا بودن به نمایشگاه که فاصله ی چندانی با ما نداشت رفتیم. یکی دو غرفه ی اول رو که دیدیم گفتیم: “نه بابا! ایران هم داره راه می افته!” تا قبل از این لحظه فکر می کردیم که فقط چند شرکت خصوصی محدود مثل خود ما هستن که به فکر تولیدات مبتنی بر خلاقیت در این عرصه هستند ولی با دیدن این غرفه ها و با تصور این که کل نمایشگاه به همین ترتیب خواهد بود نظرمون کاملا عوض شد!…

یکی از این غرفه ها به بازی “سوشیانت” تعلق داشت. شرکت “فن افزار شریف” به نظرم می تونه با کسب تجربه های بیشتر در آینده خیلی خوب عمل کنه. واقعا کارشون برای شروع خیلی خوب به نظر می رسید. به گفته ی خودشون موتور “engine” بازی کار خودشون بود و با استفاده از مایا شروع به طراحی کرده بودن. خب موتور بازی ایرانی می تونه خیلی خوب باشه!

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

طراحی ها, اسکچ ها و روایت داستان هم در نوع خودش جالب بود. با توجه به علاقه ی شدید من به اسطوره های اسکاندیناوی, آلمان و یونان باستان, بیان داستان در قالب اسطوره های ایرانی بسیار زیبا به نظرم رسید. بازی در ژانر اول شخص و نمای دوربین بالا با محدوده ی دید وسیع بود.

به هر حال با گذر از این غرفه, تقریبا بقیه ی غرفه ها به فعالیت های زیر مشغول بودند:

· نمایش لپ تاپ های “اچ پی” ای که روی چفیه های پهن شده قرار دارند.

· نمایش نرم افزار تلاوت قرآن با صدای “عبدالواسط”.

· نرم افزار نمایش عکس های 8 سال دفاع مقدس.

· سی دی مالتی مدیا ی سفرهای استانی رییس جمهور و رهبر.

· فروش کباب ترکی ممتاز.

· و یک بخش فوق العاده سرگرم کننده و مرتبط به نام “اجرای زنده ی موسیقی بندری”!

به هر حال با نگاهی اجمالی به سر و وضع بازدیدکنندگان و هیجانات آن ها می توانستی به کنح قضیه پی ببری!

فریم ورک کدایگنایتر (CodeIgniter) از بسیاری جهات برای ساخت سیستم های مبتنی بر وب عملکرد خوبی از خود نشان می ده. این فریم ورک یکی از رقبای خوب کیک پی.اچ.پی (CakePHP) محسوب می شه. در حالی که CakePHP به صورت پیش فرض از ماژول ها پشتیبانی نمی کنه, CodeIgniter با قابلیت پشتیبانی از سیستم ماژولار و اپلیکیشن های مختلف, مورد توجه بسیاری از برنامه نویسان سیستم های مبتنی بر وب قرار گرفته.

CodeIgniter از مدل MVC مبتنی بر معماری مدل, ویو و کنترلر (Model, View, Controller) پشتیبانی می کنه و تمامی کارهاشو با استفاده از این مدل انجام می ده به این ترتیب که وجود هر کنترلر برای در دست گیری اپلیکیشن و ویو برای نمایش واسط های کاربری ضروری و استفاده از مدل ها برای ارتباط با پایگاه داده اختیاری است.

پس CodeIgniter از یک معماری دو لایه ی اصلی تشکیل شده که در لایه ی اول از کنترلر تشکیل می شه, در لایه ی بعدی, مشترکا مدل و ویو در دو بخش مجزا به نمایش اطلاعات و جمع آوری آن دست می زنند. در این وضعیت هسته ی سبک CodeIgniter در پایین ترین سطح, بدون نیاز به هک شدن و یا تغییر خاص برای هر گونه اپلیکیشن به کار مشغول می شود. (عدم نیاز به هک شدن از ادعاهای نویسندگان این فریم ورک هست ولی عملا برای سیستم های پیچیده نیاز به تغییر هسته محتمل به نظر می رسه با این حال با توجه به سادگی فوق العاده ی کدهای هسته, این کار راحت به نظر می رسه)

مزیت بعدی CodeIgniter عدم پشتیبانی اولیه از ارسال فرم ها با متد get هست. با این که امکان فعال سازی این متد وجود داره ولی به دلیل این که استفاده نکردن از این متد, هم شکل URL و هم امنیت بالاتر رو حفظ می کنه, فرم غیر فعال اون و استفاده از متد post و یا ارسال سگمنت (segment) ها توصیه شده. به این ترتیب در یک url ساده, می توانید application و کنترل مورد نظر و حتی پارامترهای ارسالی رو هم بدون نیاز به یک خظ کد اضافه داشته باشید!

مثال:

Normal URL:

http://yourdomain.com/index.php?app=content&task=show_content&content_id=23

CodeIgniter URL:

http://yourdomain.com/contents/show_content/23/

از مشکلات این فریم ورک عدم پشتیبانی مستقیم از Ajax (ای.جکس یا همان آژاکس ایرانی ها!) هست که با کلک های خاصی به راحتی قابل پیاده سازی است. همچنین عدم امکان ساخت ماژول های 100% مستقل به دلیل مشکلات namespace import از دیگر ضعف های این فریم ورک است.

مبحث نخ بندی برنامه های سیستم عامل یا همون threadingاز جمله مسایلی هست که روی پایگاه های داده نقش بسزایی داره که هر مدیر database, طراح یا برنامه نویس وب باید به این قضیه نگاه عمیقی داشته باشه.

یکی از مشکلات بزرگ در هنگامی رخ می ده که چند مشتری در یک زمان اتصال (connection) باز با دیتابیس دارند و نحوه ی کدنویسی هم به صورتی هست که عملکرد هر کدوم بر دیگری تاثیر می ذاره. بذارید این سناریو رو بررسی کنیم که مثلا شما قضد دارید به کاربر با آی.دی 222 جایزه ی ویژه ای بدید. تا الان 221 بازدیدکننده به سایت شما سر زده و ثبت نام کرده اند. توجه کنید که در پروسه ی ثبت نام هیچ فیلد منحصر به فرد (unique field) دیگه ای جز آی.دی وجود نداره و همین آی.دی کلید اصلی جدول (primary key) هست. در این اثنا بازدید کننده ی شماره ی 222 وارد شده و شروع به وارد کردن اسم خودش می کنه. پس از این کار شما اسم رو ذخیره می کنید و کاربر رو به مرحله ی بعد پاس می دید. اسم با شماره ی 222 ذخیره می شه و تا این جای کار همه چیز درسته. در مرحله ی بعد شما چک می کنید که آیا جدول به شماره ی 222 رسیده که به بازدید کننده جایزه بدید و اون رو به فرم دریافت آدرس و شماره تلفن پاس بدید یا نه؟ برای این کار چه راهی پیشنهاد می شه؟

از اون جایی که عموما تمامی پروسه ی بالا در یک آن و یک مرحله ی اتصال انجام می شه, تنها چیزی که واقعا از کاربر در دست شماست اسم اونه و می خواید ببینید که نفر 222 ام هست یا نه؟ برای این کار راحت ترین راه حل مشاهده ی آخرین ردیف (row) وارد شده (inserted) در پایگاه داده هست. مسلما شما به راحتی قادر هستید با دستور (MAX id) و یا دستورات مشابه دریافت آخرین ردیف بر اساس نوع پایگاه داده ی خودتون, آخرین ردیف که احتمالا همون آقای 222 ام هست رو بگیرید. ولی چی می شه اگه بین دو تا خط دستورتون عمل threading اجرا بشه و برای چند لحظه این کد به حالت halt بره و آقای دیگه ای در اون سر جهان عمل ورود اسمش رو انجام بده! در این حالت سناریو به شکل زیر می شه:

A.insert(“hassan”); //id 222 automatically generates, auto_increment property

A.halt();

B.insert(“ali”); //id 223 automatically generates, auto_increment property

B.halt();

A.get_last_row(); //produces B row with id 223

B.get_last_row(); //produces B row with id 223

خب! هیچ کس که برنده نشد! ممکنه فکر کنید می تونید بگید آخرین ردیف وارد شده ای که اسمش hassan هست می تونه به ما کمک کنه! ولی توجه داشته باشید که ممکنه از شانس خوب شما, همون طور که threading ها افتاد وسط کد, اسم آقای دوم هم hassan باشه که اتفاقا اسم نادری هم نیست!

خود MySQL و حتی MSSQL برای غلبه بر این مشکل راه حل هایی با توابع داخلی خاصی ازایه داده اند که اکثرا فقط در مورد یک کاربر صدق می کنه ولی راه حل های عمومی تر ولی مشکل تری برای غلبه بر این مسئله و یا مسایل شبیه این وجود داره. از جمله:

· استفاده ازtransaction (تراکنش؟!) باعث می شه که بین دستوراتتون وقفه ی تاثیر گذار نیفته.

· استفاده از قفل/باز کردن جداول (lock/unlock)

· و یا استفاده از کدهای hash منحصر به فرد مختص هر کاربر که نیاز به ایجاد تغییراتی در جدول داره.

به هر حال در کار با دیتابیس و خصوصا در حیطه ی وب, علاوه بر توجه شدید به مسایل امنیتی و تزریقی, باید توجه بالایی هم به این گونه مسایل بشه…

می دونی, بدترین قسمت کار با پی اچ پی (PHP), -این زبان قشنگ- اینه که هیچ کس نمی تونه دقیقا بگه بهترین روش کار با پی اچ پی چیه؟!

با بک گراندی که از دات نت دارم می دونم که تقریبا همه ی دات نت (.net) کارها با ویژوال استودیو کار می کنن, می دونن که نحوه ی معماری نرم افزارشون چیه, مدل ها کجاست, کلاس ها چطوری طبقه بندی می شه و… ولی در زبان پی اچ پی هر کس ساز خودش رو می زنه! به همین دلیله که بی شمار فریم ورک (Framework) و سی.ام.اس (CMS) به این زبان نوشته شده که هر کدوم معماری و روش کار خودشون رو دارند.

در این مدت به ترتیب ابتدا با Macromedia Dreamweaver کد می نویسی و معمولا پروژه ها رو بدون کمک این فریم ورک ها انجام می دی, بعد کم کم با توجه به سختی کار بدون داشتن زیرساخت خوب به سمت استفاده از Content Management System هایی مثل Joomla, Drupal, EE, PHPNuke و یا حتی WordPress می ری و پس از مدتی گیجی احساس می کنی که بد نیست خودت برای پروژه هات یک CMS یا Framework اختصاصی داشته باشی و شروع می کنی به نوشتن و از این راه با کلی اصول و قواعد کاری و معماری هایی مثل MVC آشنا می شی, با Eclipse کار می کنی و پی می بری که کلا جاوا بی خودی بزرگ می شه و در نهایت بر می گردی به همون جوملا و بعد هم فریم ورک های ساده و کارایی مثل CakePHP یا Codeigniter و کار رو با Adobe Dreamweaver ادامه می دی!…

چرخه ی گیجی یک وب کار به همین جا ختم نمی شه بلکه تا بی نهایت ادامه پیدا می کنه!…

مهم این جاست که توی همه ی این گیجی ها, تجربه کسب کنی… همون طوری که برای هر کسی در زمینه ی IT توی سال اول دانشگاه این سوال پیش میاد که “چه زبانی رو به عنوان زبان اصلیم انتخاب کنم” و با گشتن بین زبان های مختلف یه یکی دو سالی فقط به همه چی ناخنک می زنه و به کسب تجربه می پردازه, در این جا هم باید بدون مقاومت, اجازه بدی مغز و احساست با هم راهت رو به سوی زبان, فریم ورک یا هر چیز دیگه ای انتخاب کنن, درست همون کاری که وقتی دنبال کیس ازدواجی انجام می دی!