خانه

برنامه‏نویسی وب

در ستایش دروپال

25 October 2009

این وبلاگ و سایت آموزشگاه با کمک Drupal راه‏اندازی شده‏اند. دروپال CMS بسیار قدرتمندی است. اگر چه شاید ظاهر مدیریتی دوست داشتنی نداشته باشد (مانند Joomla) یا شاید به روز رسانی و نصب ماژول آن آسان نباشد (به آسانی WordPress) ولی با این حال بهترین CMS برای برنامه‏نویسان است.

دروپال دارای یک Framework برنامه‏نویسی بسیار قدرتمند است و سیستم مستندات بسیار کاملی هم دارد (+) علاوه بر این از لحاظ طراحی سیستم و ساختار CMS (سیستم مدیریت محتوا) در آن نوآوری‏های بسیار خلاقانه‏ای انجام شده است.

در این نوشته فهرستی از 45 سایت مهم و جذاب که با Drupal ساخته شده‏اند را ببینید.




از شر Spammerها و کپچا، هر دو آسوده شویم

27 April 2009

Spamerها و Botها چیزهای بدی هستند و سبب می‏شوند ترافیک کاذب پایگاه بالا رفته، و هزینه سرور بالا برود و یا سبب شود که به دلیل ترافیک بالای سایت، شرکت میزبان سایت را ببندند. همچنین هزینه نگهداری چنین سایتی افزایش پیدا می‏کند و مدیر پایگاه باید دایم پیامهای Spam را پاک کند. راه حل رهایی از این وضعیت «کپچا» است ولی خود «کپچا» نیز یک جورهایی آزاردهنده است و کار بازدیدکنندگان را دشوار می‏کند.

آیا راهی وجود دارد که از شر Spammerها و Botها رها شویم ولی گرفتار شر کپچا هم نشویم؟ پیش از این برخی از پایگاه روش به کار گرفتن کپچاهای غیرتصویری را به کار برده‏اند. (برای نمونه، 2 به اضافه 7 چند می‏شود؟، پایتخت ایران کجا است؟، اصفهان در چه کشوری قرار دارد؟ و ...) اما به هر روی این‏ها نیز برای کاربران دردسر ایجاد می‏کنند؟ آیا راه حلی وجود دارد که کلا ما را از شر کپچا (از هر نوعش رها کند) و همین طور از شر Spammerها هم رها باشیم؟

خوشبختانه برنامه‏نویس‏ها هم مانند Spammerها هیچ گاه بیکار نمی‏نشینند و راههای بهتر و کم‏دردسرتری برای مبارزه با Spammerها بر می‏گزینند. یک راه حل بسیار جالب در این باره را اینجا بخوانید.

در این باره

نوشته‏ای درباره MVC و برنامه‏نویسی یک گالری با PHP

16 March 2009

فرید احمدیان نوشته خوبی درباره MVC و نوشتن یک گالری با PHP نوشته است. اینجا بخوانید.

سردرگمی میان Frameworkهای PHP - کدام یک را باید برگزید؟

19 February 2009

Frameworkهای بسیار زیادی برای PHP نوشته شده است که هر کدام ویژگی‏ها و امکانات خاص خودشان را دارد. برای برگزیدن یکی از آنها، نیاز به بررسی همه و آشنایی نسبی با آنها دارد. من مدتها بود که داشتم با اینها بازی می‏کردم و ویژگی‏ها و چگونگی کار با هر کدام را می‏آزمودم. در این نوشته پنج Framework مشهور را برگزیده‏‎ام و به بررسی کلی هر کدام از آنها خواهم پرداخت. این بررسی می‏خواهد یک Overview کلی از هر کدام را نشان دهد تا برای دیگران، انتخاب آسان‏تر شود. Framework برگزیده خودم هم در این نوشته مشخص خواهد شد و دلایل گزینش آن را نیز می‏توانید بخوانید.

Zend Framework
طبیعتا Zend Framework سرشناس‏ترین و بالاترین گزینه ما است؛ چون که Zend، شرکتی که پشت PHP است آن را طراحی و تولید کرده است. این Framework امکانات زیادی داشته و بسیار قدرتمند است و هر آن چه که برای تولید یک پروژه بزرگ لازم داشته باشید در خود دارد. License آن هم BSD است که به شدت انعطاف پذیر بوده و شرط می‏کند که در صورت توسعه آن باید کد تولید شده کاملا انعطاف پذیر باشد.

همچنین این Framework از PHP 4 پشتیبانی نمی‏کند و تنها در PHP 5 اجرا می‏شود. با توجه به تلاشهای زیاد اخیر برای ارتقاء به PHP 5 در سرورها شاید این مسئله کمتر به چشم بیاید ولی به هر روی ناهماهنگی با یکی از گسترده‏ترین نسخه‏های PHP در این Framework به چشم می‏خورد.

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

بد نیست بدانید که در بین سایتهای ایرانی، سایت مشهور کلوب با کمک Zend Framework درست شده است.

CakePHP
یکی از مشهورترین و محبوب‏ترین Frameworkها و یکی از بهترین برابرهای Rails در PHP به شمار می‏آید. از MVC کامل پشتیبانی می‏کند. کاربران خیلی زیاد و فعالی دارد که ویژگی مهمی به حساب می‏آید. اگر چه من اصلا از Mambo خوشم نمی‏آید ولی این CMS محبوب Mambo هم قرار است در نسخه‏های آینده از CakePHP استفاده کند.
اما این سیستم دو تا اشکال کوچک هم دارد. یکی این که بیش از اندازه کند است (برای خواندن گزارش یک Benchmark خوب بین CakePHP، Zend Framework و CodeIgniter اینجا را ببینید). این مساله در صورتی که هزینه سرور برای شما اهمیت داشته باشد، خودش را بیشتر نشان می‏دهد. دوم این که اسامی کلاسهایی CakePHP خیلی عمومی طراحی شده است. برای نمونه کلاس Database که اگر شما هم کلاس مشابهی داشته باشید، سبب ایجاد ناهماهنگی در کد شما می‏شود و به طور کلی چنین اسم‏گذاری و به کار نگرفتن پیشوند مناسب مانند Cake سبب بدبینی نسبی من به طراحی این سیستم شده است.
همچنین ORMی که در CakePHP طراحی شده است، توارث را پشتیبانی نمی‏کند و به باور من چندان استاندارد نیست. (با Hackهایی می‏توان مشکل توارث ORM در CakePHP حل کرد. در این باره رک: Kelnishi.com)

ولی به طور کلی نصب CakePHP خیلی ساده است و راه انداختن اولیه سایت باهاش کار ساده و آسانی است. بر خلاف Zend Framework که نمی‏دانستید از کجا باید آغاز کنید، در CakePHP خیلی سریع می‏توانید یک سایت ساده راه بیاندازید. ولی انجام کارهای پیشرفته‏تر به دلیل نبودن مستندات کافی و راهنماهای مناسب کمی با CakePHP دشوار است. در هر حال گزینه انتخابی من CakePHP هم نیست.

برای خواندن یک آموزش فارسی خوب برای کار با این برنامه رک: الوان وب

Prado
از همه گزینه‏های دیگر متفاوت است. بر پایه MVC درست نشده است. طراح Prado این کار را برای پروژه دکترایش انجام داده است و در طراحی آن Delphi را مد نظر داشته و تلاش کرده تا یک Framework کاملا Object Oriented و Event Driven درست کند. اگر با ASP.NET کار کرده باشید، Prado را خیلی مشابه با آن خواهید یافت. در Prado همه چیز حتی یک Label و Button هم Object است که Propertyها و Eventهای خاص خودش را دارد. همچنین زبانی شبیه به HTML برای طراحی ظاهر صفحات دارد (دقیقا شبیه به ASP.NET و Tagهای asp: این زبان)
من اگر چه ASP.NET را دوست دارم و باهاش کار هم می‏کنم و اگر چه فکر می‏کنم Prado سیستم خیلی قشنگ و تمیزی است ولی Prado هم گزینه برگزیده من نیست؛ چون پشتیبانی یک سیستم از MVC برایم اهمیت زیادی دارد.

CodeIgniter
این Framework خیلی شبیه به CakePHP و از آن ساده‏‎تر و کوچکتر است و به همین خاطر هم از لحاظ سرعت از CakePHP خیلی بهتر است ولی خوب به همان اندازه هم امکانات کمتری دارد. این Framework شما را مجبور به پیروی کامل از MVC نمی‏کند، بنابراین برای یادگیری نوآموزان بهتر است. از Ajax هم مستقیما پشتیبانی نمی‏کند. ولی Code Igniter ویژگی‏های خوبی هم دارد. این Framework در PHP 4 هم کار می‏کند و از لحاظ سبک برنامه‏نویسی به سبک برنامه‏نویسی PHP 4 نزدیک است. به همین خاطر برای Port کردن کدهای قدیمی به یک Framework گزینه مناسبی است. همچنین دارای Community بزرگی است و کامپوننتها و مثالهای فراوانی برایش پیدا می‏شود. این Framework هم همانند CakePHP گزینش من نیست.

symfony
این Framework امکانات بسیار زیادی دارد و ماژول‏های جداگانه را برای انجام کارهای خودش به کار می‏گیرد: مانند DB Layer که با امکانات زیاد خودش واقعا لایه بانک اطلاعاتی شما را به بهترین شکل پشتیبانی می‏کند و امکان نوشتن برنامه مستقل از بانک اطلاعاتی را به شما می‏دهد. (اگر چه این ویژگی در Frameworkهای دیگر هم هست).
برای انجام پروژه‏های بزرگ symfony به خاطر امکانات زیادش، گزینه خیلی خوبی است ولی با این حال، پیچیدگی‏های Zend Framework را هم ندارد. این Framework هم تنها بر روی PHP 5 کار می‏کند. License آن هم MIT است که License خوب و انعطاف‏پذیری به حساب می‏آید. همچنین این Framework به خوبی AJAX را پشتیبانی می‏کند و امکاناتی برای ساختن صفحات Admin سایت دارد که کار طراحی بخش مدیریتی سایت را خیلی آسان می‏کند.

سیمفونی از ORM مشهوری به نام Propel بهره می‏گیرد که به باور من سیستم بسیار قدرتمندی است. اگر چه در CakePHP هم ORM هست ولی در آن جا از یک سیستم داخلی استفاده شده است. به کار گیری یک ORM بیرونی سبب افزایش سرعت توسعه سیمفونی شده است؛ چون که Propel سیستم خیلی مشهوری بوده و به طور عادی خودش در حال توسعه هست. این مساله همچنین هوشمندی طراحان سیمفونی را نشان می‏دهد.

خوب حدس زدنش سخت نیست. Framework برگزیده من symfony است. طراحی دقیق و محکم، سرعت مناسب، امکانات خیلی زیاد، مستندات و Community بزرگ آن، وجود ویژگی Admin Generator و سیستم کنترل دسترسی که سبب می‏شود من بتوانم در زمان طراحی صفحات سایت به مسائل مهمتر و افزودن ویژگی‏های اصلی بپردازم، از دلایل این گزینش من است.

پیوندها

آدرسهای تر و تمیز یا من چگونه با جستجوگرها دوست شدم؟

13 February 2009

Clean URL و Friendly URL و Search Engine Friendly URL همگی نامهای گوناگونی است که برای یک چیز گذاشته‏اند. فرض کنید که شما به عنوان برنامه‏نویس در بخش مدیریت به مدیر سایت اجازه داده‏اید تا صفحات مورد نظر خود را ایجاد کند. شما این صفحات را در بانک اطلاعاتی می‏نویسید. حالا کاربر با زدن نشانی زیر می‏تواند، محتوای این صفحه را ببیند:

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

البته روشن است که در سایت شما واقعا فایلی به اسم page-47.aspx وجود ندارد و این تنها یک آدرس مجازی یا یک Alias به آدرس واقعی است.

انجام این کار در Apache و PHP به سادگی آب خوردن است. کافی است افزونه Mod_Rewrite را در Apache فعال کنید (این افزونه در بیشتر میزبانهای امروزی فعال است) و در شاخه اصلی سایتتان فایلی به نام .htaccess درست کنید و در آن یک Rule یا قانون Rewrite بنویسید. چیزی شیبه به این کار را راه می‏اندازد:


RewriteEngine On
RewriteBase /
RewriteCond % !-f
RewriteCond % !-d
RewriteRule . /index.php [L]

در این Rule هر درخواستی که به این سایت انجام شد به فایل index.php فرستاده می‏شود. حالا در فایل index.php خیلی ساده می‏شود با $_SERVER["REQUEST_URI"] نشانی مجازی که کاربر وارد کرده است را پیدا کرد و محتوای مناسب با آن را به کاربر نشان داد. بر این اساس اگر کاربر نشانی site.com/products/1 را وارد کنید شما در فایل index.php می‏توانید نشانی products/1 را پیدا کنید، و صفح محصول اول را به او نشان دهید. در حالی که واقعا هیچ شاخه‏ای به اسم products و 1 وجود ندارد.

انجام این کار هیچ وقت در IIS و ASP به راحتی Apache نبوه است. برای این کار لازم است تا در فایل Global.asax خودتان یک رویداد BeginRequest بنویسید. این رویداد در آغاز رسیدن Request به Web Server فراخوانی می‏شود. حالا در این رویداد می‏توانید با کمک HttpContext مسیر فعلی یا (incoming) را پیدا کرده و بر اساس نیاز خودتان با کمک متند RewritePath مسیر مجازی را به مسیر واقعی تبدیل کنید.

یک نمونه خیلی ساده این کار:

protected void Application_BeginRequest(object sender, EventArgs e)
{
HttpContext incoming = HttpContext.Current;
string oldpath = incoming.Request.Path.ToLower();
string pageid; // page id requested

// Regular expressions to grab the page id from the pageX.aspx
Regex regex = new Regex(@"page(\d+).aspx",  RegexOptions.IgnoreCase |
RegexOptions.IgnorePatternWhitespace);
MatchCollection matches = regex.Matches(oldpath);

if(matches.Count > 0)
{
// Extract the page id and send it to Process.aspx
pageid = matches[0].Groups[1].ToString();
incoming.RewritePath("Process.aspx?pageid=" + pageid);
}
else
// Display path if it doesn’t containt pageX.aspx
incoming.RewritePath(oldpath)
}
}

ما در اینجا همه مسیرها را به فایل Process.aspx فرستاده‏ایم. حالا باید چنین فایلی را درست کنید و در آن به سادگی با کمک Request.QueryString["pageid"] می‏توانید شماره صفحه مورد نظر کاربر را پیدا کنید.

کلیدواژه: URL Rewriting

سردرگمی میان رنگها: آن گاه که طراحان وب، رنگ کم می‏آورند

13 February 2009

اگر Color-Depth یا عمق رنگ نمایشگرهای پشرفته امروزی را 32 بیت در نظر بگیریم (به نسبت نمایشگرهای 8 بیتی یا حتی 4 بیتی قدیم و حتی از آن بدتر 2 بیتی) در تئوری می‏شود 4,294,967,296 رنگ را در این نمایشگرها نشان داد. یعنی این نمایشگرها می‏توانند چهار میلیارد رنگ را نشان دهند.

خوب شاید تا این اندازه ترکیب رنگی متفاوت نداشته باشیم ولی اگر فرض کنیم در فضای رنگی RGB رنگ می‏سازیم، 256*256*256 رنگ یعنی ما امکان ساختن 16,581,375 رنگ را داریم. خوب 16 میلیون رنگ هم کم نیست. ولی مشکل این جاست که گاهی همین طراحان وب، با این حال رنگ کم می‏آورند یا در میان این 16 میلیون رنگ نمی‏توانند ترکیبی رنگی را برگزینند که با سایر رنگهای به کار رفته آنها همخوانی داشته باشد.

طراحان وب برای حل مشکل دست به دامن مفهومی به نام Color Wheel یا گردونه رنگ شده‏اند. گفته می‏شود، نیوتون نخستین کسی است که یک گردونه رنگی درست کرده است؛ اگر چه، من چیز زیادی در این باره که آیا به راستی نیوتون نخستین کس بوده است یا نه، نمی‎‏دانم. اما به قول دنگ زیائوپینگ که می‏خواست عملگرایی‏اش را نشان دهد: «من اهمیتی نمی‏دهم که یک گربه سیاه است یا سفید. تا آن گاه که موشها را شکار می‏کند، گربه خوبی است» حالا همه مهم نیست که گردونه رنگ، تئوری نیوتون بوده یا نوبده. تا هنگامی که برای من خوب کار می‏کند، ابزار سودمندی است.
گردونه رنگ خیلی ساده، بر پایه همان منشور رنگهای آینه‎‏ای درست شده است که برخی از ما در بچگی درست می‏کردیم. سه، چهار، پنج یا شش آینه را به درازی 20 و عرض 3 تا 4 سانتی‏متر می‏دادیم که ببرند (پدری، برادری، آینه‏بری، بالاخره یکی را پیدا می‏کردیم).

بعد اینها را در کنار هم قرار می‏دادیم و دورش را از این چسبهای برق ضحیم می‏چسباندیم. در نهایت می‏شد یک ابزار لوله مانند. حالا هنگامی که در داخل این ابزار لوله مانند نور آفتاب تابانده می‏شد، رنگهای جالبی تشکیل می‏گردید که خودِ من کلی با آن ذوق می‏کردم ((:

اگر می‏خواهید درباره تئوری‏های پشت این منشورهای رنگی بخوانید اینجا و اینجا توضیحات خوبی آمده است. از این سخن‏ها که بگذریم، چند ابزار انتخاب رنگ خوب:


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

این انتخاب‏کننده رنگ نسخه آنلاین برنامه ColorSchemer Studio 2 است و امکانات محدودتری نسبت به خود این برنامه دارد. در این سایت یک گالری از ترکیب رنگهای مختلف هم وجود دارد که به جای این که خودتان ترکیب رنگ بسازید، می‏توانید آن را به کار گیرید

این یک Plugin برای Photoshop است که کار شما در زمان طراحی صفحات خیلی خیلی آسان می‏کند. یکی از ویژگی‏های بسیار خوب این برنامه، امکان پیدا کردن ترکیب رنگ‏های مناسب از تصویر موجود شما است.

این سایت هم با Flash است و برنامه خیلی خوبی را طراحی کرده است. برنامه این سایت تا حدودی شبیه به برنامه kuler.adobe.com است. اما یکی از ویژگی‏های محشر این برنامه که من خیلی دوستش دارم که ترکیب رنگ ساخته شده شما را به صورت Preview در یک صفحه سایت تستی نشان می‏دهد. برای این کار از گوشه سمت راست برنامه گزینه Light page example و Dark page example را انتخاب کنید.

این برنامه ویژگی خیلی خوبی که دارد این است که به شما اجازه می‏دهد تصویر اصلی که می‏خواهید در Header یا در پس‏زمینه یا در هر جای دیگری از سایتتان به کار ببرید را Upload کنید و بر اساس این رنگ، ترکیب رنگهای مناسب را بیابید.

این هم سایت خیلی ساده و کوچولویی است و برای هنگامی که عجله دارید، مناسب است.

این برنامه را باید داونلود کنید و ای چندان بدک نیست.

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

چگونه از شر Cache Server لعنتی آسوده شویم؟ یا من چگونه Cache Server را کشتم؟

11 February 2009

اگر طراح وب باشید حتما با مشکلاتی که Cache Serverها درست می‏کنند درگیر شده‏اید. دارید روی یک پروژه وب کار می‏کنید. همه تغییرات را در کامپیوتر محلی خودتان انجام می‏دهید و آماده فرستادن تغییرات می‏شوید. Style.css، تصاویر و فایلهای دیگر خود را می‏فرستید و سپس با خیال آسوده می‏خواهید بروید نتیجه را آنلاین ببینید. F5 را می‏زنید گررررررر تغییرات جدید نشان داده نمی‏شود. Ctrl + F5 را می‏زنید. افاقه نمی‏کند. Cache مرورگر را خالی می‏کنید. باز هم افاقه نمی‏کند. از یک مرورگر دیگر استفاده می‏کنید. باز هم، همان نسخه پیشین نشان داده می‏شود.
و این جاست که بر پدر و مادر تمامی کسانی که Cache Server را ساخته‏اند، درود می‏فرستید.

Cache Server چیست و چرا مشکل ایجاد می‏کند؟

Cache Server خدمات‏دهنده‏ای است که در مراکز خدمات‏دهنده اینترنت نصب شده و صفحات وب یا فایلهای جانبی صفحات وب را بر روی خود ذخیره می‏کند تا در صورت درخواستِ دوباره کاربران به مشاهده آن صفحات، آنها را دوباره از سرور اصلی بارگزاری نکرده و آنها را از محل ذخیره خود برای کاربر بفرستد تا سبب کاهش هزینه پهنای باند گردد.
Cache Serverها بر پایه این اصل بنا شده‏اند که چند کاربر ممکن است نیاز به مشاهده پایگاهها یا منابع یکسان داشته باشند (برای نمونه ممکن است 30% کاربران یک خدمات‏دهنده اینترنت، سایتهای یکسانی را مشاهده می‏کنند؛ برای نمونه یک سایت خبری یا یک سایت عمومی)
Cache Server اولین تقاضایی که برای مشاهده یک سایت (برای نمونه isna.ir) شد را در خود ذخیره می‏کنند. از این به بعد هر کاربر دیگری که مایل به دیدن این صفحه باشد، نسخه ذخیره شده بر روی Cache Server را دریافت کرده و دوباره سایت از سرور اصلی دریافت نمی‏شود.

اگر چه باید گفت که Cache Server مکانیزم‏هایی برای تشخیص ایجاد تغییر در نسخه ذخیره شده بر روی سرور خود و نسخه اصلی روی سرور را دارند؛ ولی در هنگام طراحی یک سایت، این مکانیزم‏ها به درستی پاسخ نمی‏دهد. زیرا تغییراتی که طراح در سایت می‏دهد لحظه به لحظه است و Cache Server این احتمال را نمی‏دهد که این سایت به این سرعت تغییر کرده باشد، بنابراین فایلهای style.css و فایلهای تصویری را که در درون خود ذخیره کرده است (که قدیمی بوده و نسخه‏های جدیدی که شما به تازگی ارسالی کرده‏اید را شامل نمی‏شود) را برای کاربر می‏فرستد و از این رو شما تغییرات انجام شده خود را نمی‏بینید.

شاید برایتان این پرسش پیش بیاید که چرا سرویس‏دهندگان خدمات وب Cache Server نصب می‏کنند؟ پاسخ ساده است، خدمات‏دهندگان اینترنت برای پهنای باند هزینه می‏کنند و از این طریق می‏توانند سبب کاهش هزینه‏های خود در زمینه پهنای باند باشند.

با کدام Cache Server می‏جنگیم؟

باید بدانیم که ما همیشه با توجه به اینترنتی که از آن استفاده می‏کنیم با چند Cache Server برابر هستیم. برای نمونه اگر در سازمان شما اینترنت از طریق ISA Server برای کاربران Share شده باشد و Cache Server در آن فعال شده باشد، در این صورت شما در نخستین گام با Cache Server داخلی سازمان خود برابر هستید. همچنین اگر سازمان شما از سرویس‏دهنده اینترنت x سرویس گرفته باشد و این سرویس‏دهنده اینترنت، Cache Server نصب کرده باشد یا شاید حتی ماژول سخت‏افزاری Cache داشته باشد، شما در گام دوم با Cache Server سرویس‏دهنده خود برابر هستید.

همچنین همه می‏دانیم که همه مرورگها نیز به نوعی دارای یک Cache Server هستند که فایلها را در آن ذخیره می‏کنند. این Cache Server در IE با نام Temporary Internet Files و در FireFox با نام Browsing History شناخته می‏شود.

راههای مبارزه با Cache Server

  • استفاده از کلید Ctrl + F5: این راه تنها به درد مبارزه با Cache Server مرورگر می‏خورد. در واقع شما به جای این که هر بار Cache مرورگر را خالی کنید، می‏توانید با زدن کلید Ctrl + F5 از مرورگر بخواهید که فایلها را دوباره از خدمات‏دهنده اینترنت دریافت کند. این راه برای مبارزه با Cache Server خدمات‏دهنده اینترنت کارا نیست.
  • فریب Cache Server با تغییر ظاهری URL: برخی پیشنهاد می‏کنند که با حذف www یا اضافه کردن چند کاراکتر Slash الکی در پایان آدرس Cache Server را فریب داد. یعنی اگر دفعه اول سایت خود را به صورت http://www.sample.com دیده‏اید این بار به صورت http://sample.com یا به صورت http://sample.com/// ببینید. زیرا هر بار Cache Server فکر می‏کند که با سایت تازه‏ای روبرو است و از این رو سایت را دوباره از سرور اصلی دریافت می‏کند. اما این روش با Cache Serverهای پیشرفته امروزی جواب نمی‏دهد. به عبارت دیگر Cache Serverهای امروزی (برای نمونه در Cache Server موجود در ISA Server همه آدرسهای بالا یکسان هستند) افزون بر این، حتی اگر Cache Server این دو آدرس را یکسان تشخیص ندهد، باز یک مشکل اساسی باقی است. منابعی که در صفحات شما به کار رفته است (برای نمونه یک فایل CSS) هنوز با آدرس پیش‏فرضی که شما آنجا نوشته‏اید فراخوانی می‏شود و باز هم Cache Server جلوی آن را می‏گیرد.
  • استفاده از فی.لت.ر شکن: این روش اگر چه پاسخ می‏دهد ولی یک مشکل اساسی دارد. سرویس‏دهنده از این به بعد آدرسی صفحه‏ای را که فی.لت.رشکن دریافت کرده است Cache می‏کند و باز روز از نو روزی از نو.
  • استفاده از دامین جایگزین: برخی پیشنهاد می‏کنند که از دامینهای جایگزین استفاده شود. این روش نیز چندان عملی نیست. مگر سایت ما چند تا دامین جایگزین دارد؟ بالاخره آنها هم Cache می‏شوند و سایت ما این وسط گرفتار می‏ماند.
  • تنظیم Cache-Cotnrol در HTML به صورت زیر: 
<META HTTP-EQUIV="CACHE-CONTROL" CONTENT="NO-CACHE">

این روش هم پاسخ نمی‏دهد؛ زیرا بیشتر Cache Serverها جوری تنظیم شده‏اند که به این Tag اهمیتی نمی‏دهند. در واقع تمام اینترنتهای متخلفی که من در این چند سال در ایران دیده‏ام به این تگ کاملا بی‏اهمیت هستند.

بهترین و عملی‏ترین راه برای مبارزه با Cache Server چیست؟


روند کار Cache Serverها این گونه است:
1- کاربری درخواست دیدن سایت http://isna.ir را کرده است. اگر این سایت در Cache هست برو به 2 و اگر نیست برو به 3.
2- صفحه http://isna.ir را از روی Cache Server برای کاربر بفرست. برو به 4.
3- صفحه http://isna.ir را از روی سرور اصلی دریافت کن و آن را در Cache Serve ذخیره کن تا وقتی که کاربر بعدی یا همین کاربر در بار دوم درخواست دیدن این صفحه را کرد، از Cache Server برای او فرستاده شود.
4- پایان

خوب با توجه به این که بر اساس پروتوکل HTTP به همراه هر درخواستی می‏توان یک Query String فرستاد، آدرس http://sample.com/index.php?keyword=iran و http://sample.com/index.php?keword=qom دو نشانی متفاوت به حساب می‏آیند؛ اگر چه هر دو در حال بارگزاری یک فایل مشترک (index.php) هستند. Cache Server هم این دو نشانی را یکسان در نظر نگرفته و هر دو را مجددا از روی سرور بارگزاری می‏کند. بر این اساس دو نشانی http://sample.com/style.css?q=1 با http://sample.com/style.css?q=2 متفاوت است، اگر چه هر دو در واقع از یک فایل استفاده می‏کنند.

برای همین من برای جلوگیری از Cache شدن فایل Style.css از کدی شبیه به این استفاده می‏کنم تا هر بار یک عدد Random تولید شده و Cache Server گول بخورد. (:

<link rel=stylesheet href="http://sample.com/style.css <?php echo "?q=".mt_rand(1, 1000000) ?>" type="text/css">

شما همین طور برای جلوگیری از Cache شدن فایل HTMLتان می‏تواند پس از فایل HTML یک Query String الکی وارد کنید و این طوری بود که من توانستم Cache Server را بکشم.

توجه داشته باشید که وقتی Development سایتتان تمام شد و دیگر نخواستید تغییری انجام دهید، حتما این مکانیزم را از صفحاتتان حذف کنید. زیرا Cache Server با همه معایبی که برای طراحان وب دارد، در نهایت سبب افزایش سرعت صفحات برای کاربران نهایی هم خواهده شد. زیرا صفحات از سرور محلی کاربر برای او فرستاده می‏شود که زمان کمتری نسبت به بارگزاری صفحات از سرور اصلی می‏برد.

Syndicate content