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

ایندکس‌ها

وقتی روی یک یا چند ستون ایندکس بذارید mysql یک فهرست از رکوردها که بر اساس اون یک یا چند ستون مرتب شده باشند تهیه و ذخیره میکنه که بعد از این فهرست میتونه برای جستجو و مرتب سازی سریع رکورد ها استفاده کنه.

استفاده از ایندکس ها برای دیتابیس های حجیم اجتناب ناپذیره. ولی یادتون باشه در استفاده از ایندکس ها  زیاده روی نکنید. ایندکس ها سرعت نوشتن و آپدیت کردن رو کند میکنند و حجم جداول رو هم افزایش میدن.
برای اینکه ببینید کجا لازمه از ایندکس استفاده کنید میتونید از تنظیم log-slow-queries استفاده کنید تا کوئری هایی که زمان اجراشون بیش از مقداری که در تنظیم long_query_time تعریف شده باشه لاگ بشه. از تنظیم log-queries-not-using-indexes هم میتونید استفاده کنید تا کوئری هایی که از ایندکس استفاده نمیکنند رو پیدا کنید (توضیحات بیشتر). بعد میتونید با استفاده از EXPLAIN کوئری‌های مربوطه رو بررسی کنید و در صورت لزوم روی فیلدهایی که لازمه ایندکس بذارید.
البته همه کندی ها مربوط به ایندکس نداشتن نیست گاهی اوقات هم میشه با تغییر در برنامه و بازنگری در کوئری ها بدون افزودن ایندکس  مشکلات رو رفع کرد.

MyISAM یا InnoDB

MyISAM و InnoDB دو تا engine معروف mysql هستند. با اینکه MyISAM سرعت بیشتر و حجم کمتری داره ولی معمولا برای  دیتابیس های حجیم از InnoDB استفاده میشه. این کار سه تا علت عمده داره:

• InnoDB  در عملیات نوشتن از row-level lock استفاده میکنه ولی MyISAM از table-level lock استفاده میکنه.
  به عبارت دیگه InnoDB وقتی میخواد یک رکورد بنویسه یا آپدیت کنه فقط همون یک رکورد رو قفل میکنه ولی MyISAM کل جدول رو قفل میکنه. این تفاوت باعث میشه زمانی که تعداد عملیاتهای نوشتن و آپدیت زیاده سرعت InnoDB بیشتر باشه. به عبارتی این عملیات ها در InnoDB میتونن همزمان اجرا بشن ولی در MyISAM هر عملیات باید منتظر اتمام عملیات قبلی بمونه.
• جداول InnoDB در هنگام کرش کردن احتیاجی به repair ندارند ولی جداول MyISAM در صورت کرش کردن باید repair بشن.
  عملیات repair عملیات فوق العاده زمان بری هست. برای همین استفاده از MyISAM برای جداول حجیم مناسب نیست. من یک جدول MyISAM با حدود 60 میلیون رکورد رو خواستم repair کنم که بعد از گذشت دو روز و تموم نشدن عملیات مجبور شدم kill کنمش و چاره‌ای دیگه بیاندیشم.
• از جداول InnoDB میشه در حالیکه دیتابیس فعاله Hot Backup تهیه کرد(با استفاده از XtraBackup) ولی برای تهیه Hot Backup از جداول MyISAM باید جداول Lock بشن که باعث میشه در زمان تهیه بکاپ readonly باشند (مگر اینکه از LVM یا replication برای بکاپ گیری استفاده کنیم).

InnoDB و MyISAM تفاوت‌های دیگه ای هم دارند مثلا اینکه InnoDB از Transaction و Foreign Key پشتیبانی میکنه ولی MyISAM پشتیبانی نمی‌کنه. همینطور MyISAM از Full-text index پشتیبانی میکنه ولی InnoDB پشتیبانی نمی‌کنه.

یکسری نکات دیگه در مورد InnoDB هست که کمتر توی اینترنت در موردش صحبت شده که عدم آگاهی از اونها میتونه دردسر ساز بشه.

مثلا اینکه با حذف رکورد از جداول InnoDB حجم جداول کاهش پیدا نمیکنه و فضای مربوط به رکوردهای حذف شده آزاد نمیشه. البته این فضا بعدا برای رکوردهای جدید مصرف خواهد شد.
ضمنا InnoDB در حالت پیشفرض داده‌های همه جداول InnoDB مربوط به همه دیتابیس ها رو در یک فایل مشترک(ibdata1) ذخیره می‌کنه در این حالت حتی با حذف جدول هم فضای مصرفی اون جدول آزاد نمیشه. برای همین اگر قصد استفاده از InnoDB رو دارید حتما تنظیم innodb_file_per_table رو در فایل my.cnf قرار بدید تا داده‌های هر جدول در شاخه‌ی دیتابیس مربوطه و با نام متناظر با جدول ذخیره بشه. البته یادتون باشه که حتی در صورت استفاده از این گزینه باز هم جداول InnoDB مستقل نیستند و وابسته به فایلهای ibdata1 و ib_logfile ها هستند. به عبارتی با کپی گرفتن از شاخه یک دیتابیس و منتقل کردنش به یک سرور دیگه نمیشه جداول InnoDB رو منتقل کرد و همچنین برای تهیه پشتیبان کپی کردن شاخه دیتابیس تنها کافی نیست. در حالی که اینکارها برای جداول MyISAM براحتی امکان پذیره.
البته برای انتقال یک جدول InnoDB بین دو دیتابیس روی یک سرور می‌تونید از RENAME TABLE استفاده کنید.

InnoDB بر خلاف MyISAM تعداد رکوردها رو ذخیره نمی‌کنه. که باعث میشه COUNT گرفتن بدون استفاده از WHERE روی جداول InnoDB خیلی زمان‌بر باشه و برای جداول حجیم عملا غیر ممکن باشه. در واقع نیاز به استفاده از COUNT بدون WHERE به ندرت پیش میاد که احتمالا قابل صرف نظر کردن هست. البته اگر رکوردی از جدول حذف نمی‌کنید می‌تونید به جای COUNT از MAX(id)‎ استفاده کنید. یک راه دیگه استفاده از Trigger هست که توصیه نمیشه چون performance رو پایین میاره.

در ضمن برای استفاده بهینه از InnoDB در صورتی که از سرور اختصاصی برای mysql استفاده می‌کنید می‌تونید مقدار innodb_buffer_pool_size را حدود 70-80 درصد از حافظه RAM قرار بدین. (توضیحات بیشتر)

ALTER

زمانی که بخواهید تغییری در ستون های جداول ایجاد کنید یا ایندکس حذف یا اضافه کنید و یا engine جدول رو تغییر بدید روش معمول استفاده از دستور ALTER هست که خیلی  زمانبر هست. یک جایگزین سریعتر برای Alter اینه که یک جدول خالی با تغییراتی که مد نظرتون هست بسازید و بعد با استفاده از INSERT INTO new_table SELECT * FROM old_table  اطلاعات رو به جدول جدید منتقل کنید. و یا در صورت کمبود حافظه ابتدا با استفاده از SELECT INTO OUTFILE خروجی تهیه کنید و سپس با LOAD DATA INFILE اطلاعات رو به جدول جدید منتقل کنید. این روش حدود 50 درصد از ALTER سریعتر هست. (توضیحات بیشتر)

تغییر در جداول حتی با استفاده از روشهای فوق هم عملیات زمانبری است و اگر بخواهید بدون Downtime روی جداول حجیم تغییرات ایجاد کنید تنها راه استفاده از Replication است که در ادامه مطلب در موردش توضیح میدم.

Replication

برای اینکه میرور لحظه‌ای از دیتابیس خود داشته باشید باید از replication استفاده کنید.
در replication ما یک سرور master داریم که با استفاده از قابلیتی به نام Binary log همه عملیات هایی که منجر به تغییرمیشه نظیر Insert و Update وDelete  و Alter و … رو لاگ میکنه. بعدا سرور یا سرورهای slave که حاوی میروری از دیتابیس های سرور master هستند از این binlog ها برای اعمال همان تغییرات روی میرورها و بروز نگهداشتن میرورها استفاده میکنند. در این حالت باید همه‌ی عملیات هایی که منجر به تغییر میشن فقط روی سرور master اجرا بشن و از سرورهای slave فقط برای خوندن استفاده بشه. در غیر اینصورت میرورها از سینک خارج میشن.

استفاده از replication و binary log کاربردهای زیادی داره از جمله:

• Load Balancing
  وقتی یک سرور جوابگوی پاسخ به همه حجم ترافیک نباشه باید از چند تا سرور استفاده کرد. خوب در مرحله اول میشه وبسرور و سرور mysql رو جدا کرد. اما وقتی یک سرور اختصاصی برای mysql هم جوابگو نبود باید از replication استفاده کرد تا بار پردازشی بین چند تا سرور توزیع بشه. با توجه به اینکه معمولا حجم عملیات نوشتن کمتر از حجم خواندن از دیتابیس هست میشه برنامه رو طوری طراحی کرد که از سرور master فقط برای نوشتن استفاده کنه و از سرورهای slave برای خوندن.
• Failover
  تصور کنید دیتابیس حجیمتون به خاطر یک اشکال سخت افزاری یا نرم افزاری از کار بیافته طوریکه مجبور باشید دیتابیس رو از روی بکاپ ها بازیابی کنید. این کار بسته به حجم دیتابیس ممکنه ساعتها طول بکشه و در مورد یک سرویس اینترنتی ممکنه ثانیه ها هم ارزش داشته باشند. اینجاست که از replication برای failover استفاده میشه. به این صورت که به محض مشکل دار شدن سرور master یکی از سرورهای slave تبدیل به master میشه. و از اون لحظه به بعد همه عملیات های نوشتن اون رو انجام میشه و سایر slave ها هم خودشون رو از اون رو بروز میکنند. بعد از رفع مشکل سرور master قدیمی به عنوان یک سرور slave وارد مدار میشه.
  
• Backup
  بعضی ها replication رو با بکاپ اشتباه می‌گیرند. برای روشن شدن موضوع یک مثال میزنم. فرض کنید روی سرور اصلی یک نفر اشتباها یک کوئری drop اجرا کنه و یک جدول مهم رو پاک کنه. در این صورت این کوئری روی سرورهای slave هم اجرا میشه و دیگه نمیشه از slave ها به عنوان پشتیبان استفاده کرد و اطلاعات رو برگردوند. بنابراین replication به تنهایی راه حلی برای بکاپ گیری نیست.
  اما ببینیم چطور میشه از replication برای بکاپ گیری استفاده کرد.
  در روش اول میشه از binary log به تنهایی (بدون استفاده از replication) برای تهیه بکاپ افزایشی (Incremental) استفاده کرد. به این صورت که یکبار از کل دیتابیس پشتیبان تهیه می‌کنید بعد از اون هر روز binary log های اون روز رو روی پشتیبان اجرا می‌کنید تا همیشه یک پشتیبان بروز داشته باشید بدون اینکه نیاز باشه هر روز از کل دیتابیس پشتیبان تهیه کنید. و در صورت بروز مشکل میتونید از روی binary log ها پشتیبان خود را تا لحظه قبل از وقوع مشکل بروز کنید. (کل این عملیات با استفاده از ابزار XtraBackup به راحتی قابل انجامه).
  روش دوم اینه که از یک سرور slave استفاده کنیم تا هیچ downtime و بار پردازشی روی سرور اصلی ایجاد نشه. در این حالت با خیال راحت میتونیم سرور slave رو stop کنیم و از دیتابیس بکاپ تهیه کنیم و مجددا سرور رو استارت کنیم. بعد از استارت شدن سرور مجددا شروع به بروز شدن از همان لحظه توقف میکند.
• ALTER بدون downtime
  یکی دیگه از کاربردهای replication تغییر در ساختار جداول بزرگ هست. همون طور که قبلا گفتم Alter دستور زمان بری هست. طوری که ممکنه برای یک جدول حجیم یک تغییر نظیر افزودن ایندکس روی یک فیلد یا اضافه کردن یک ستون جدید به جدول ساعت ها یا حتی روزها طول بکشه. توی این حالت برای اینکه downtime نداشته باشیم میتونیم از یک سرور slave استفاده کنیم به این صورت که ابتدا روی سرور slave دستور STOP SLAVE رو اجرا میکنیم تا عملیات بروز شدن از master متوقف بشه. بعد تغییرات رو روی جداول مورد نظر می‌دیم. بعد از اتمام تغییرات دستور START SLAVE رو اجرا میکنیم تا مجددا سرور ما از سرور اصلی بروز بشه. بعد از اینکه مطمئن شدیم سرور slave ما با سرور اصلی sync هست جای سرور slave و master رو عوض می‌کنیم. حالا میتونیم سرور master قدیمی(که الان slave هست) رو هم تغییرات رو روش اعمال کنیم و به عنوان slave ازش استفاده کنیم.
• کاربردهای خاص
  از replication برای کاربردهای خاص دیگه ای هم میشه استفاده کرد. مثلا فرض کنید ما به Full-text search روی یکی از فیلدهای یک جدول InnoDB احتیاج داشته باشیم. و نخواهیم به دلایلی که گفته شد از MyISAM استفاده کنیم. در این حالت میتونیم از replication استفاده کنیم. به این صورت که جدول ما روی سرور اصلی InnoDB هست ولی روی یکی از سرورهای slave که مخصوص full-text search ایجاد کردیم همان جدول را از نوع MyISAM داریم. حالا برنامه رو طوری طراحی میکنیم که برای کوئری هایی که احتیاج به full-text search هست از این slave استفاده کنه.

حرف آخر

در نهایت یادتون باشه خودتون رو محدود به mysql نکنید شاید اصلا mysql گزینه مناسبی برای کار شما نباشه. این روزها تب دیتابیس های NoSQL هم داغ هست یک سری به اونها هم بزنید. برای نمونه mongodb دیتابیس فوق العاده ای برای کارهای بزرگ هست. بنچمارک ها نشون میده سرعتش از mysql خیلی بیشتره و قابلیت های فوق‌العاده ای نظیر Map-Reduce و پشتیبانی خیلی خوب از Replication و Sharding داره. اگر فرصت کنم در یک مطلب جداگانه در موردش مفصل توضیح میدم.

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

این شد که دست به کار شدم و WebExtract رو با پایتون نوشتم. این برنامه یک Daemon هست که به صورت یک سرویس نصب میشه و روی پورت 2121 سرویس میده و از یوزر و پسورد های سیستم برای احراز هویت استفاده میکنه. به عبارتی بعد از نصب این برنامه کاربر با رفتن به آدرس سایت خودش روی پورت 2121 می‌تونه با وارد کردن نام کاربری و رمز ftp ، فایلها و فولدرهای خودش رو ببینه و فایل های فشرده رو آنلاین باز کنه.

در ادامه نحوه نصبش رو توضیح میدم.

قبل از هر چیز این نکته رو بگم که برای نصب این برنامه باید دسترسی root به سرور داشته باشید. به عبارتی اگر میخواین این امکان رو روی هاستتون داشته باشید باید با مدیر سرورتون تماس بگیرید و ازش بخواهید که این برنامه رو براتون روی سرور نصب کنه. (که البته اگر نصب نکرد کاری از من ساخته نیست و اگر هم نصب کرد مسئولیتش با خودشه!)

اما نحوه نصب:

برای اجرای این برنامه باید پایتون 2.5 به بالا داشته باشید که اگر ندارید میتونید از سایتش دریافت، کامپایل و نصب کنید:

wget http://www.python.org/ftp/python/2.7/Python-2.7.tgz
tar xvfz Python-2.7.tgz
cd Python-2.7
./configure
make
make install

بسته‌ی webextract رو هم از اینجا دریافت و نصب ‌کنید:

wget http://github.com/downloads/farhadi/webextract/webextract-1.0.tar.gz
tar xvfz webextract-1.0.tar.gz
cd webextract-1.0
make install

برنامه آمادست. در ضمن پورت 2121 هم باید روی فایروال سرور باز باشه.

اگر موقع باز کردن فایلهای فشرده با خطای «sorry, you must have a tty to run sudo» مواجه شدید باید دستور visudo رو اجرا کنید و دنبال خط «Default requiretty» بگردید و کامنتش کنید و ذخیرش کنید. (دیگه vi باید بلد باشید.)

در صورت لزوم پورت برنامه رو هم می‌تونید در فایل ‎/etc/webextract.conf تغییر بدید. البته یادتون باشه بعد از تغییر، برنامه رو restart کنید. (‎/etc/init.d/webextract restart)

من این برنامه رو روی debian ، ubuntu و CentOS تستش کردم ولی باید روی همه‌ی توزیع های بر پایه دبیان و ردهت کار کنه.

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

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

اینجا به مناسبت های مختلف نظیر 22 بهمن و روز قدس و سالگرد انتخابات و … اینترنت دچار اختلال میشه. طوری که تقریبا از اینترنت جز پروتکل http چیز دیگه ای باقی نمی‌مونه. و هیچ نهاد و ارگان و سازمانی هم مسئولیت این اختلالات رو به عهده نمی‌گیره.
شاید برای کاربران عادی عمق این فاجعه مشخص نباشه ولی این اختلالات میتونه خسارات جبران ناپذیری برای شرکت ها و صنایع وابسته به اینترنت داشته باشه. مثلا پرداخت های اینترنتی رو در نظر بگیرید که به خاطر قطعی https می‌تونه باعث لغو یک قرارداد یا آزاد شدن یک دامنه و یا خیلی مشکلات دیگه بشه. برای نمونه ما برای پرداخت هزینه یک سرور اختصاصی برای یک مشتری به خاطر اختلال بوجود آمده دچار مشکل شدیم. از یک طرف باعث بد قولی و بی اعتبار شدن ما پیش مشتری میشه از طرفی هر روز تاخیر در راه اندازی سرور کلی خسارت به مشتری وارد میکنه و در نهایت تاخیر در پرداخت باعث اضافه شدن جریمه تاخیر به قرارداد و بد حساب شدن ما میشه. یا یک نمونه دیگه عدم دسترسی مشتری های هاستینگ به پنل مدیریت هاستشون به خاطر اختلال https هست. که باعث نارضایتی مشتری‌ها میشه. از طرفی اختلال در دسترسی SSH به سرورها هم مشکلات عدیده ای رو برامون بوجود میاره.
یک نمونه دیگه هم بسته شدن دسترسی به فایل های فلش خارج از کشور بود که باعث شده بود یکسری گزارشات و امکاناتی که با استفاده از فلش تولید شده بود از کار بیافتند. این مورد هم علاوه بر اینکه کلی از مشتری ها رو شاکی کرده بود کلی وقت هم از تیم فنی گرفته شد تا پی به علت اشکال ببرند.
آخرین نمونه هم امروز بود که به خاطر اشکال دسترسی https امکان تمدید و ثبت دامنه IR وجود نداره و معلوم هم نیست کی درست بشه. خوشبینانه ترین حالت اینه که 48 ساعت این قطعی ادامه داشته باشه و همین قدر کافیه تا کلی خسارت به مالکان دامنه های درحال انقضا وارد بشه. خلاصه از این دست مشکلات و خسارات بسیارند و هیچ کس مسؤلیت این خسارات رو بعهده نمی‌گیره.

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

مشکل دیگه ای که کاربران اینترنت ایران ازش رنج می‌برند محدودیت 128 کیلوبیتی سرعت دسترسی برای کاربران خانگی هست.
این طرز تفکر که این سرعت برای مصارف خانگی کافیه از اونجا ناشی میشه که مسئولین مربوطه تصور میکنند تنها کاربرد اینترنت چت کردن و دوستیابی و در نهایت بازدید از چند صفحه وب هست و خلاصه اینکه تصور میکنند اینترنت یک ابزار تفننی است.
الان دنیا به جایی رسیده که از سیستم عامل های تحت وب و سرویسهای ابری (cloud) و اپلیکشن‌های تحت وب استفاده میشه در حالی که ما حتی درک درستی هم از این مفاهیم نداریم. البته اگر اکثریت مردم ما جز چت و دوستیابی استفاده‌ی مفید دیگری از اینترنت نمی‌کنند به این خاطر است که با این سرعت کاری غیر از این هم نمی‌شود کرد. در واقع ما با اعمال این محدودیت مانع از ظهور و رشد کاربردهای مفید اینترنت می‌شیم.

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

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

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

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

به هر حال امیدوارم روزی برسه که مسئولان به اهمیت این موضوع پی ببرند و ما شاهد اینترنتی در شأن مردم ایران باشیم.

این تصویر در سال 1995 توسط ادوارد ادلسون پروفسورای علوم بصری منتشر شد.

نکته جالب اینجاست که حتی بعد از اینکه می‌فهمی دو مربع یک رنگ هستند باز هم باور نمی‌کنی!

در واقع ما نمی‌بینیم، مغز ما می‌بینه و پردازش میکنه و ما حاصل پردازش رو درک می‌کنیم.

آپدیت:

حدود یک سال و نیم پیش آقای محمدی یک اسکریپت جالب برای تستش نوشتند که میتونید اینجا ببینید.

در ضمن توی این صفحه علت این خطای دید توضیح داده شده.
توی پاراگراف پایانی نوشته «این تصویر بر خلاف سایر حقه های تصویری به جای اینکه خطای سیستم بینایی رو ثابت کنه صحت عملکرد سیستم بینایی رو ثابت میکنه. سیستم بینایی نورسنج فیزیکی خوبی نیست اما هدف این نیست. وظیفه اصلیش اینه که اطلاعات تصویر رو تبدیل به اجزاء معنی دار کنه و بوسیله اونها ماهیت اشیایی رو که می‌بینه تشخیص بده»

منبع

پرکاربردترین کلید واژه Id است که ترکیبی از سایر کلید واژه ها شامل نام فایل، شماره rev و تاریخ و مولف است.

برای مثال ممکن است قبلا چیزی شبیه خط زیر را در ابتدای فایلی دیده باشید :

$Id: calc.c 148 2006-07-28 21:30:43Z sally $

این همان قابلیت Keyword Substitution در svn است که عبارت $Id$ را با عبارت فوق جایگزین کرده است.

با استفاده از این قابلیت وقتی از پروژه export می گیرید در ابتدای هر فایل اطلاعات مولف ، تاریخ و شماره revision را دارید که ممکنه بعدها به دردتون بخوره.

و اما نحوه فعال کردن این قابلیت :

svn propset svn:keywords "Id" myfile.php

این دستور باعث میشه کلید واژه Id برای فایل myfile.php فعال بشه. و بنابراین هر جا در این فایل عبارت $Id$ قرار داشته باشه در هنگام کامیت با اطلاعات مربوطه جایگزین میشه و در کامیتهای بعدی هم به صورت خودکار آپدیت میشه.

در ضمن اگر از TortoiseSVN  استفاده می کنید از منوی TortoiseSVN قسمت properties می توانید از این قابلیت استفاده کنید.

اطلاعات بیشتر

آپدیت : برای فعال کردن این قابلیت روی تمام فایل های php موجود در یک شاخه (و زیر شاخه های آن) به مسیر مورد نظر رفته و دستور زیر را اجرا کنید:

find -type f -name "*.php" -exec svn propset svn:keywords "Id" {} \;

برای حذف این قابلیت از روی یک فایل دستور زیر را اجرا کنید:

svn propdel svn:keywords myfile.php

برای رفع این معضل یک راه سرخ پوستی پیدا کردم با استفاده از htaccess و ماژول mod_rewrite :

1. دامنه مورد نظر (مثلا addon.com) رو پارک می کنید روی هاست (توی plesk به جای پارک میگن domain alias)
2. یک شاخه با نام addon.com توی فولدر httpdocs می سازید.
3. یک فایل .htaccess در شاخه httpdocs با محتوای زیر ایجاد میکنید:

# addon.com addon domain.
RewriteEngine on
RewriteCond %{HTTP_HOST} ^addon\.com [OR]
RewriteCond %{HTTP_HOST} ^www\.addon\.com
RewriteCond %{REQUEST_URI} !^/addon\.com/
RewriteRule ^(.*) /addon.com/$1 [L]

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

با یک traceroute و ping گرفتن و مقایسه با سرور قبلی همه چیز روشن شد. نتیجه traceroute به سرور ایرانی فقط 5 تاhop بود در حالی که این تعداد برای سرور قبلی 22 تا بود و این یعنی کاهش تعداد روترهای بین من و سرور از 22 تا به 5 تا که باعث شده زمان ping از حدود 700 میلی ثانیه به 100 میلی ثانیه برسه.

اینجاست که میشه به اهمیت اون جمله معروف پی برد که میگه :
“these days, bandwidth is cheap, latency expensive”

اکثر کشورهای خارجی به لحاظ پهنای باند مشکلی ندارند و مشکل اصلی اونها latency (تاخیر) هست . حالا ما که مشکل پهنای باند داریم و نمیتونیم بیشتر از 128Kb برای مصرف خانگی داشته باشیم لااقل میتونیم با انتقال سایت‌ها به سرورهای ایرانی زمان تاخیر(latency)  رو کم کنیم. اینکار چند تا فایده اخلاقی هم داره. یک اینکه وابستگی مون به خارج کم میشه. دو اینکه امکان تحریم سرورها دیگه وجود نداره. و سوم اینکه از خروج ارز جلوگیری میشه.

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

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

فایل هاش رو گذاشتم رو هاستم تا اگر قصد امتحان کردنش رو داشتید برای دانلودش دچار درد سر نشید.

android_sdk_linux_m3-rc22a.zip

android_sdk_windows_m3-rc22a.zip

این هم پلاگینش برای eclipse

ADT-0.3.1.zip

راستی اگر android هم مثل بقیه کارهای گوگل همه گیر بشه دیگه جایی تو زندگی آدمها باقی نمی مونه که گوگل توش نباشه.

وای به روزی که گوگل بد بشه. شایدم هست !!

آپدیت(18-03-87): به دلیل کمبود جا فایل ها رو از رو هاستم پاک کردم.

واقعا جالبه !!!

این همه پیشرفت در عرض 20 سال.

معلوم نیست 20 سال دیگه چی بشه.

منبع: digg

http://www.poodwaddle.com/worldclock.swf

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

این آمار از طریق اطلاعات و آمار واقعی موجود محاسبه میشه، برای اطلاعات بیشتر در مورد این ساعت و منابع مورد استفاده‌ی اون، صفحه زیر رو ببینید :

http://www.poodwaddle.com/worldclock.htm

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