آیا Reactive Manifesto واقعا مهمه؟

وقتی بین همکارا بحث کارایی بالای نرم‌افزار یا پاسخویی در زمان بسیار پایین به تعداد کاربران بسیار زیاد می‌شه، همیشه این بحث به وجود میاد؛ ما که توییتر و فیسبوک نیستیم! ما که این همه کاربر نداریم و نیازی هم نیست برای رسیدن به بالاترین کارایی و سرعت تلاش کنیم. به عبارت دیگه Reactive Manifesto برای ما نیست!

این صحبت تا حدی درسته اما وقتی مثال‌های واقعی رو بررسی کنیم ظاهرا خیلی هم درست نیست!

فیسبوک حدودا ۶۰ هزار سرور در سراسر دنیا داره (که البته تا الان خیلی بیشتر شده) تا بتونه جوابگوی حدود ۲ میلیون کاربر فعالش باشه. پس هر کدوم از سرور‌های فیسبوک به ۳۳ هزار نفر پاسخ می‌دن که خیلی هم عدد بزرگی نیست!

وقتی پاسخویی به ۳۳ هزار نفر روی یه سرور، شاهکار به حساب میاد، اهمیت توجه به مفاهیمی مثل BigData، برنامه‌نویسی همروند و Non-blocking و در کل Reactive Programming مشخص میشه. یادمون نره که Facebook فقط ظاهرش PHP هست ولی باطنش هر چیزی غیر از اون PHP‌ هست که ما میشناسیم؛ فقط بخاطر اینکه بتونه سرعت خیلی بالایی داشته باشه.

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

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

پس اینکه بگیم ما Facebook و Twitter نیستیم دلیل نمیشه که به کارایی بالا توجه نکنیم. البته باید دقت کنیم دلیلی هم نداره که خود پروژه رو فدای مسائل تکنیکی کنیم!

پیشنهاد من اینه که اگر میخواییم توی تولید نرم‌افزار باقی بمونیم، باید مفاهیمی مثل Reactive Manifesto رو جدی بگیریم.

این خانه از پایبست ویران است

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

نمی‌خوام مثل اکثر مردم فقط سیاه نمایی کنم ولی بعد از کلی سفید نمایی و امیدواری و تلاش برای بهبود اوضاع اطرافم لازم میدونم یه مسائلی رو برای همگونه‌های خودم (کسایی که سبک زندگیشون شبیه منه) بگم. واقعا نمی‌دونم تاثیرش مثبته یا منفی!

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

چندتا نرم‌افزار با آخرین تکنولوژی دنیا ساخته شده، تا به جای اینکه برای اجرا به یه سرور چند ۱۰ میلیون تومانی (یا شاید چند ۱۰۰ میلیون تومانی) نیاز داشته باشه، روی یه سرور که از لپ تاپم ضعیت‌تره اجرا بشه و از همه مهمتر اینکه ۱۰ میلیارد تومان (نه ریال) از تراکنش‌های مالی سازمان مربوطه از طریق این نرم‌افزار انجام شد. حالا این سازمان دولتی حاضر نیست برای پشتیبانی از این سیستم‌ها به اضافه پشتیبانی از دو وب سایت مهمش و همینطور نگهداری سرورهاش و هزار کوفت و زهرمار دیگه، ماهی یک میلیون تومان هزینه کنه!

بعضی از آدمهایی که در مورد زیاد بودن این هزینه تصمیم میگیرن خودشون با بنز C Class و با راننده شخصی رفت و آمد میکنن. حتی چایی که میخورن با بقیه کارمندا فرق داره! هزینه نگهداری این بنز و راننده و … چند برابر مبلغ این قرارداد پشتیبانی هست! دوباره به مبلغ‌ها و آورده‌های این پروژه نگاه کنید.

جالب اینجاست که من هیچ اصراری برای انجام این پروژه نداشتم و بعضی از مدیران رده پایین‌تر داخل این سازمان باعث شدن که این کار رو قبول کنم. کاری نداریم که اولش به من سه تا فرم ساده که جمعا ۳۰ تا فیلد هم نمیشد دادن و گفتن سیستم هیچی بیشتر از این نیست و من قیمت رو بر اساس اون دادم ولی بعدش سیستم تبدیل شد به یه قول بی شاخ و دم! و البته با موفقیت انجام و اجرا شد.

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

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

بعد از یه کم بررسی و فکر، به این نتیجه رسیدم که ۸۰ درصد افراد داخل سازمان‌های بزرگ کشور، نیروی مازاد هستند و با هزینه بسیار اندک میشه با یه نرم‌افزار خوب جایگزینشون کرد. نگران از بین رفتن شغل نباشید! این موقعیت‌ها شغل نیستن اینها عین بیکاری هستن. مگه میشه یه زمین فوتبال رو پر از آدمهایی کرد که نه تنها برای برد تیم هیچ تلاشی نمیکنن بلکه ایستادن یه جا و برای هم تیمی‌ها جفت پا میگیرن تا با مخ برن تو زمین؟

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

بالاخره دست از کار کشیدم و اعلام کردم تا قرارداد امضاء نشه و پول ندن کار نمیکنم.

اگر قرارداد امضا بشه و چند برابر این پول رو هم بدن من واقعا دلم نمیخواد این کار رو ادامه بدم. این کار از هر نظر باعث بدبختیه من میشه. مشکل اینجاست که یه نفر توی این موسسه به من اعتماد کرد و از اعتبار خودش برای اجرای این کار مایه گذاشت، تا با یه تکنولوژی عجیب و جدید کار انجام بشه. اگر من این کار رو رها کنم اعتبار اون شخص میره زیر سوال. همین! غیر از این آب از آب تکون نمیخوره. آدما دوباره بر میگردن به همون سیستم سنتی که اتفاقا بهتر هم میشه توش زیرآبی رفت و همه چیز بر میگرده به روال خوشحال گذشته. هر چی باشه ۲۸ سال بوده که همون سیستم برقرار بوده و ما یه دفعه همه چیز رو به هم ریختیم!

یه سوال؛ واقعا از من توقع میره که بمونم ایران و این مسائل رو (حالا به سهم خودم یا هر چی) درست کنم؟ واقعا این انتظار وجود داره؟ شما جای من بودید چیکار میکردید؟

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

پ.ن: چند روز پیش یه ویدئو دیدم که تاریخ جغرافیایی ایران رو به صورت Timeline روی نقشه نمایش میداد. برای اولین بار دلم برای ایران سوخت! ولی به هر حال من خودم رو «زمینی» میدونم تا «ایرانی». فقط همین یه کم بهم آرامش میده.

به روز رسانی:

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

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

به هر حال این گلدون نابود هم بشه تاثیر خاصی توی زندگی من نداره و نخواهد داشت. ولی برای این کشور خیلی تاثیر گذاره.

خلاصه اهمیت مالی موضوع صفره! مسئله اینجاست که این خونه‌ای که از پایبست ویرانه رو باید چیکارش کرد؟

چه ابزاری بهتره؟

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

به نظرم توی این بازی میشه با دوتا استراتژی جلو رفت:

  1. یک سلاح رو که از همه بهتره برداریم و کلا بچسبیم به همون و دیگه درگیر خرید و تعویض و این چیزها نشیم
  2. از انواع سلاح و ابزار استفاده کنیم. مثلا استفاده از نارنجک، Shield و … که در این صورت لازمه حسابی توی تعویض ابزارها و استفاده به موقعه ازشون حرفه‌ای بشیم

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

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

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

نکته: Simple != Easy ؛ ممکنه چیزهایی که ما امروز پیچیده میدونیمشون، بعدها ازشون به عنوان یه چیز ساده (نه الزاما آسون) یاد بشه.

حال و احوال و تغییرات

تغییرات

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

اتفاقات این دو سه ماه

متاسفانه از فرودین هیچ پستی نذاشتم. بدجوری سرم شلوغ بود. خیلی خبرا بود.

اول از همه از اواخر پارسال یه قرارداد شش ماهه با شرکت راستین افزار آریا بستم تا سه روز در هفته حضور فیزیکی توی شرکت داشته باشم که تقریبا دو ماه دیگه ازش مونده. آخرین باری که به این شکل کار کردم یادم نیست! تا اینجا که خیلی جالب بود و درسهای خوبی گرفتم و البته پولش هم خوبه 🙂 ولی هنوز نمیدونم دلم میخواد مثلا برای یه شش ماهه دیگه ادامه بدم یا نه. دلیل این تصمیم این بود که بتونم به صورت خیلی منظم‌تر (سه روز دیگه هفته رو) روی پروژه شخصی خودم کار کنم که البته انقدر کارهای دیگه پیش اومد که نشد مرتب و منظم روش کار کنم.

بعد از ۲۸ سال برگزاری نمایشگاه کتاب تهران، برای اولین بار سیستم ثبت نام ناشران این نمایشگاه به شکل الکترونیکی انجام شد. این یک پروژه یک نفره بود که خوشبختانه انجام شد ولی متاسفانه خانه کتاب و خیلی‌های دیگه همکاری نکردن و کار اونطوری که دوست داشتم نشد. مهمتر از همه ما کار رو کوچکتر از چیزی که بود در نظر گرفته بودیم و بعضی از ناشرا اذیت شدن. از همه مهمتر واقعا از سواد کم کامپیوتری ناشرای محترم کشورمون شدیدا در تعجب هستم!

از طرف دیگه همزمان با راه اندازی سیستم  ثبت نام نمایشگاه کتاب، سیستم بن کتاب رو هم دوباره به شکل یک نفره پیاده سازی و اجرا و راه اندازی کردم. بیشتر از ۲۰۰ هزار نفر از طریق این سیستم ثبت نام کردند (که میشه بیشتر از ۸ میلیارد تومن).

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

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

یه خبر مهم دیگه اینکه قراره برای ۱۰ سالگی تهلاگ (Tehlug) (اگر نشه شاید یکی از جلسات معمولی لاگ) یه ارائه کامل داشته باشم از تجربیاتی که برای این دوتا پروژه داشتم. احتمالا طیف مطالبش گسترده باشه. از برنامه‌نویسی و بانک اطلاعات و … تا نگهداری سرور و پاسخگویی به ۵۰۰ درخواست در ثانیه و خوابیدن سرور و … ولی هرچی هست اسکالا نقش پررنگی داره.

چند وقت پیش هم یه لاینس IntelliJ IDEA خریدم. به مناسبت ۲۰مین سالگرد تولد زبان جاوا یه تخفیف خوب داده بودن. با Payment24 پرداخت کردم. در کل شد حدود ۵۰۰ هزار تومن. اولش خیلی خوشحال بودم. بعد که باهاش کار کردم دیدم ساپورتش از Play Framework یه مقداری ضعیفه. از قضا چند روز قبل از اینکه IDEA رو بخرم Scala IDE یه نسخه جدید داده بود که نسبت به نسخه قبلی خیلی بهتر شده بود، پشتیبانیش از Play هم از IDEA کنونی بهتره، هرچند IDEA هر زبان و پلتفرمی که فکرش رو بکنید پشتیبانی میکنه. به هر حال هر کدوم از این ابزارها یه حسن‌هایی دارن و به مرور زمان بهتر هم میشن. واقعا نمیدونم چرا اول نسخه Trialش رو نصب نکردم بعد بخرمش!

فرصت که پیدا میکنم سریال Silicon Valley رو هم دارم میبینم که بسیار بسیار به مذاق ماها خوش میاد 🙂

یک سال پس از مهاجرت به لینوکس

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

از سال ۱۳۸۲ به طور حرفه‌ای (برای پول درآوردن) برنامه‌نویسی می‌کنم و بیشتر آن روی تکنولوژی‌های مایکروسافت بوده. اگر نگویم تمام ابزارها، بیشتر ابزارهایی که در این چند سال استفاده کردم محصول مایکروسافت بود؛

  • ویندوز به عنوان سیستم عامل
  • آفیس برای کارهای اداری
  • Outlook برای ایمیل و تقویم و …
  • Internet Explorer به عنوان مرورگر!
  • استفاده بیشتر از Bing نسبت به Google برای جستجو!
  • گوشی هوشمند با سیستم عامل ویندوز فون ۷ (Mozart 7)
  • صفحه کلید (ارگونومیک) و ماوس مایکروسافت!!!
  • استفاده از نرم‌افزارهای متن باز دات نتی (حتی برای وبلاگ به جای ورد پرس)
  • Visual Studio برای تولید نرم‌افزار (از طراحی تا پیاده‌سازی)
  • SQL Server برای بانک اطلاعاتی
  • زبان سی شارپ و سکوی دات نت
  • و …

windows-tattooهر کاری که میخواستم انجام بدهم حس بهتری داشتم که با محصولات مایکروسافت باشد. چون مایکروسافت به توسعه دهنده‌ها اهمیت میداد و زبان سی شارپ هم کار آنهاست و در کل جایگزینی خوبی برای سی شارپ نداشتم! از آنجایی که من برنامه نویس هستم بیشتر عمرم را مشغول صحبت کردن با یک زبان برنامه‌نویسی هستم پس اهمیت این موضوع که با چه زبانی کار کنم و اینکه این زبان چه امکاناتی داشته باشد روشن است.

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

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

برای یک پروژه شخصی در حال بررسی سرور و از این قبیل بودم که متوجه شدم خرج زیادی دارد. خواستم از SQL Server استفاده نکنم ولی هرچه گشتم هیچ جایگزین رایگان درست و حسابی برای آن وجود ندارد، اگر هست با بقیه ابزارهای مایکروسافت (مثل EF) جور در نمی‌آید. متوجه شدم این مورد فقط در خصوص SQL نیست و بقیه ابزارها هم همینطور است (همان قضیه مجتمع مسکونی). برای یک برنامه نویس گیر کردن در چنین وضعی مثل این است که یک عقرب را در دیواری از آتش محصور کنی!

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

dawn-700x300

ولی افتاد مشکل‌ها! حالا باید از صفر تا صد همه کارها را در دنیایی متفاوت انجام می‌دادم. من هم ابزارهای زیر را برای کارهایم انتخاب کردم:

  • اوبونتو به عنوان سیستم عامل
  • لیبره آفیس به جای آفیس مایکروسافت
  • Thunderbird (و پلاگین‌هایش) به جای Outlook
  • ابتدا Chromium و بعدها (به خاطر مشکلی امنیتی) Firefox به جای IE
  • استفاده بیشتر از محصولات گوگل
  • گوشی ویندوز فون ۷ را هنوز داشتم (و دارم ولی دلم یک گوشی اندرویدی می‌خواهد که بتوانم رویش Firefox OS یا Ubuntu Touch نصب کنم) ولی یک تبلت اندرویدی گرفتم و تازه دنیای اپ‌ها به رویم باز شد
  • صفحه کلید فراسو و ماوس A4tech!!!
  • استفاده از ورد پرس و پرستا شاپ و نرم‌افزارهای غیر دات نتی (که تعدادشان خیلی بیشتر از دات نتی‌ها بود)
  • Scala IDE (همان Eclipse) و IntelliJ IDEA و بقیه برای توسعه نرم‌افزار
  • MongoDB، Postgres و MySQL برای بانک اطلاعاتی
  • زبان اسکالا و بعدا روبی و پایتون (در کنار اسکالا) برای برنامه‌نویسی (هنوز اسکالا را به شدت نسبت به بقیه ترجیح می‌دهم)
  • و …

و مشکلاتی که داشتم؛

  • هنوز یک پروژه بر روی دات نت داشتم و با استفاده از Virtual Box یک نسخه ویندوز ۷ با VS روی آن بالا می‌آوردم و با بدبختی روی آن کار میکردم؛ بسیار کند بود و وقتی دکمه Alt را می‌گرفتم منوی Unity باز می‌شد و وسط نوشتن یک کد حساس یک حال اساسی به اعصابم می‌داد.
  • دلم می‌خواست روی پروژه‌ای با زبان اسکالا کار کنم ولی کسی حتی اسمش را هم نشنیده بود!
  • من عادت کرده بودم زبان صحفه کلید را با دست راست و با Alt+Shift سمت راست تغییر دهم ولی به دلیل وجود باگی در Ubuntu آن زمان فقط امکان استفاده از Alt+Shift سمت چپ وجود داشت و من هم هنوز بلد نبودم سیستم را هک کنم (منظور فقط کمی ور رفتن با سیستم است) و هر کلیدی که دوست دارم انتخاب کنم و تصورش را هم نمی‌کردم این باگ به سرعت رفع شود برای همین به ترکیب سمت چپ عادت کردم و هنوز هم از کلیدهای سمت چپ استفاده می‌کنم!
  •  کارت گرافیکم به سختی نصب می‌شد و فن لپ تاپ همیشه روشن بود، نصفی از مشکل بخاطر درایور کارت گرافیک بود و نصف برای تنظیمات و درایور مخصوص DELL
  • از نظر مالی شدیدا به مشکل خورده بودم، پول لازم بودم و پروژه‌ای هم در کار نبود و شرایط به شدت برایم سخت شده بود در حالی که با مشکلات بالا هم سر و کله می‌زدم و همزمان اسکالا هم یاد می‌گرفتم

البته توانستم کم کم مشکلات را حل کنم:

  • سعی کردم واقع بین باشم و وقت بیشتری بر روی پروژه دات نتی صرف کنم (اما نه انقدر واقع بین که لینوکس را پاک کنم و برگردم روی ویندوز مثل آدم کار کنم) پروژه به جای خوبی رسید و تقریبا تحویل شد. هر چند چون پروژه دولتی بود و افراد سازمان عوض شدند پروژه اجرایی نشد.
  • با ور رفتن و مطالعه، هر کاری که می‌خواستم را در Ubuntu انجام میدادم، کارت گرافیک و بقیه مسائل حل شد. برای اکثر کارهای تکراری هم یک Bash Script تهیه میکردم. به این ترتیب سرعت کارهایم بیشتر از زمان ویندوز شده بود و روز به روز احساس راحتی بیشتری می‌کردم.
  • من در دوره‌های شناخت توانایی‌های امیر مهرانی شرکت کرده بودم و یکی از چیزهایی که یاد گرفته بودم این بود که باید روی نقاط قوتم تمرکز کنم تا سریعتر به نتیجه برسم. یکی از راه‌های فهمیدن نقاط قوت نگاه به گذشته و بررسی موقعیت‌هایی است که در آن موفق بودیم. من هم همین کار را کردم و به چند سال قبل دقت کردم و همان کارها را تکرار کردم. رزومه‌ام را تکمیل و با ظاهری جدید بازسازی کردم و شروع به معرفی خودم به اشخاص و شرکت‌های مختلف کردم. بعد از ارسال تقریبا ۲۰ ایمیل، چند موقعیت خیلی خوب پیش آمد. با آدم‌های بسیار حرفه‌ای و جالبی آشنا شدم. کیفیت کارها و سطح آدم‌ها بسیار بالاتر از زمانی بود که روی پلتفرم مایکروسافت کار می‌کردم.

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

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

ubuntu-boot-small

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

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

مقایسه روبی و اسکالا: یک-هیچ به نفع اسکالا

یکی از محاسن ریلز (روبی) وجود کتابخانه‌هایی مثل Active Admin است که کارش ایجاد یک کنترل پنل با کمترین میزان نیاز به کد نویسی می‌باشد. در واقع صفحات کنترل پنل در هنگام اجرا رندر می‌شوند. قبلاً هم چنین کاری را با سی شارپ و ASP.NET MVC کرده بودم که البته از نتیجه کار راضی نبودم و پروژه واقعاً شکننده شد. البته طراحی Active Admin بسیار زیباتر و بهتر از طراحی من است.

اما وقتی بخواهیم یک صفحه خاص (Customized) را با استفاده از Active Admin طراحی کنیم باید با مطالعه مستندات یاد بگیریم که چطور می‌شود این کار را انجام داد. دقت کنید که هیچ راه دیگری جز مطالعه سورس کتابخانه و یا مطالعه مستندات و آزمون و خطای زمان اجرا (Run-time) برای کار با یک کتابخانه در روبی وجود ندارد. در صورتی که در زبان‌های استاتیک (مخصوصا اسکالا و پلی فریمورک) حداقل به ما اجازه می‌دهند از کامپایلر و یا بهتر از آن از IDE استفاده کنیم و بدون مطالعه مستندات از همان ابتدا بدانیم ورودی و خروجی متدها چه هستند یا در بدترین حالت حداقل نام متد چیست! و در نوشتن آن اشتباه نکنیم! در این شرایط به اندازی کافی کار و سر درگمی وجود دارد که اشتباه نوشتن نام یک فیلد یا یک متد هم بخواهد به آن اضافه شود.

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

شاید من برنامه‌نویس خنگی هستم ولی فقط برای ساخت فرم زیر حدود ۳ ساعت وقت صرف کردم؛

فرمی که فقط فیلدهای زیر را دارد؛

  • سال (عدد)
  • ماه (عدد)
  • اطلاعات قبلی حذف شوند؟ (چک باکس)
  • فایل (برای آپلود)

فایل CSV را از کاربر دریافت کرده و آن را در بانک اطلاعات وارد (Import) می‌کند.

با در نظر گرفتن اینکه در زبان روبی تازه کار هستم، اگر این کار را با اسکالا انجام می‌دادم (با فرض اینکه در اسکالا هم تازه‌کار بودم) قطعا زمان بسیار کمتری می‌برد.

دینامیک بودن یک شمسیر دو لبه است و گاهی اوقات کارهای بسیار جالبی می‌توان با آن انجام داد ولی تجربه به من نشان داده که پیاده‌سازی غلط زبان‌های استاتیک تا امروز باعث این حس شده که آن‌ها زبان‌های دست و پا گیری هستند. اسکالا دست و پا گیر نیست!

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

روند ارزیابی ادامه دارد…

اطلاعات جالبی از بازدید کنندگان وب سایت نمایشگاه کتاب تهران

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

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

بازه زمانی این آمار از ۶ تا ۱۰ اردبیهشت ۱۳۹۳ می‌باشد. نمایشگاه کتاب ۱۰ اردیبهشت افتتاح شد و ۲۰م به پایان رسید.

این آمار مربوط به بازدید کنندگان منحصر به فرد است که در این بازه زمانی حدود ۳۰۴ هزار نفر بوده‌اند.

بازدید کنندگان جهانی

countries

بیشتر بازدیدکنندگان از ایران بودند ولی با وجود اینکه میهمان ویژه نمایشگاه امسال افغانستان بود بازدیدکنندگان آمریکا و اروپا و خیلی جاهای دیگر، بیشتر از افغانستان بودند 😀

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

بازدید کنندگان ایرانی

iran

طبق آمار، بازدیدهای اصفهان بیشتر از هر جای دیگر حتی تهران بوده است.

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

روند بازدید در روزهای مختلف

days

روزی که بیشتر از همه بازدید داشتیم روز افتتاحیه (۱۰ اردیبهشت) بوده است و تقریبا بعد از آن روند نزولی داشته‌ایم.

نتیجه اخلاقی ندارد!

روند بازدید در ساعات مختلف

hours

بیشترین بازدید مربوط به ساعت ۱۱ صبح است. این الگو در روزهای تعطیل تغییر می‌کند.

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

سیستم‌های عامل

os

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

در انتهای لیست سیستم‌عامل‌های جالبی وجود دارند. QNX یک سیستم‌عامل Realtime است که واقعاً نمی‌دانم چطور ۳ نفر با استفاده از آن سایت را مشاهده کردند؟ البته ممکن است مربوط به سیستم‌های مانیتورینگ باشد. و از آن جالب‌تر ویندوز ۹۸ است!!! ۴ نفر با استفاده از ویندوز ۹۸ از این وب سایت بازدید کردند!

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

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

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

و اما مرورگرها

browsers1

لیست بالا ۲۵ مرورگر پر استفاده در بین بازدیدکنندگان را نمایش می‌دهد. و لیست پایین جایگاه IE 5.0 را نشان می‌دهد:

browser_ie5

هر چند در بین ۵۰ مرورگر کم بازدید قرار گرفته اما ۴ بازدید کننده داشتیم که با این مرورگر سایت را مشاهده کردند. از صمیم قلب آرزو داشتم بدانم چرا و چگونه این چهار نفر با IE 5 سایت را مشاهده کردند، در کجا زندگی می‌کنند و از چه امکاناتی برخوردارند؟ آیا با مودم Dial-up به اینترنت متصل شده‌اند؟ اصلا هدفشان از اتصال به اینترنت چه بود؟ آیا می‌خواستند تست کنند که سایت ما با IE 5 هم قابل مشاهده است؟ همین سوال‌ها را از آن ۴ نفر که با ویندوز ۹۸ آمده‌اند (که احتمالا همین ۴ نفر هستند)  هم دارم.

نتیجه اخلاقی: بیشتر مراجعه کنندگان دارای امکانات HTML 5 و CSS 3 هستند و این جای خوشحالی دارد و به طور قطع استفاده از ویژگی‌های جدید HTML و CSS پذیرفته شده است.

موتورهای جستجو

searchengine

نتیجه اخلاقی:‌ گوگل اختلاف واقعاً فاحشی (حتی شاید وحشیانه) با بقیه موتورهای جستجو دارد.

و ترافیک مصرفی در ۳۰ روز گذشته

traffic

اپ‌های موبایل نمایشگاه

چند شرکت اقدام به تولید نرم‌افزارهای تحت موبایل برای نمایشگاه کتاب کردند که آمار دانلود صورت گرفته آن‌ها به شرح زیر است:

  1. نرم‌افزارهای اندرویدی جمعاً ۱۴,۰۷۶ مورد کلیک (دانلود)
  2. نرم‌افزار آی او اس ۳,۴۲۲ مورد کلیک

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

چند نکته

  1. در ساعات اولیه روز به خصوص روزهای تعطیل، بعد از ویندوز ۷، بیشترین بازدید توسط سیستم عامل اندروید صورت می‌گرفت
  2. با استفاده از این روش محاسبه کردم که به طور متوسط ۴.۸ درخواست در هر ثانیه بر روی سرور بوده است
  3. تعداد کانکشن‌های باز بر روی پورت ۸۰ با استفاده از دستوری که قبلاً توضیح داده بودم در ساعات شلوغی به ۸۰۰ عدد می‌رسید
  4. بیشتر مراجعات بعد از صفحه خانه به صفحه جستجوی کتاب بوده است
  5. اطلاعات کتب توسط مرکز دیگری تهیه و به ما تحویل می‌شود و متاسفانه محل بسیاری از کتاب‌ها در نمایشگاه مشخص نبود

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

سرعت فضایی Scala و Play Framework و Mongo

so_happy_small

از شعف در پوست خود نمی‌گنجم!

برای پروژه اخیر اسکالا یک سرور مجازی بر روی یک سرور مجازی دیگر راه انداختم. چون سرور اصلی مجازی بود VMWare جواب نداد و از VirtualBox و مد Binary Translation که کندترین حالت مجازی سازی است استفاده کردم. ۱ گیگابایت رم و ۴۰ گیگابایت هارد به آن اختصاص دادم. یک سرور ۳۲ بیتی اوبتو ۱۲.۰۴ روی آن نصب کردم. بعد جاوا، MongoDB، Play Framework و بقیه. و خلاصه پروژه را رویش بالا آوردم.

یک سرور Git هم برای خودکار سازی انتشار برنامه بر روی سرور نصب کردم و با یک اسکریپت ساده برنامه را بر روی سرور Publish می‌کنم.

سرعت اجرا و پاسخگویی برنامه واقعاً عجیب است! یک لحظه شک کردم که شاید دارم با نسخه روی سیستم خودم کار می‌کنم. به یکی از بچه‌ها هم زنگ زدم و خواستم سایت را چک کند. او هم از سرعت بالای سایت تعجب کرد. همه چیز عالی و با سرعت و دقت کار می‌کند در حالی که فقط حدود ۱۰۰ مگابایت از رم سرور مصرف شده بود با فقط یک CPU  تک هسته‌ای ۳۲ بیتی که دو مرتبه مجازی سازی شده! 

رکوردهای یکی از جداول را زیادتر کردم تا به تعداد بیشتر از ۲۶۰،۰۰۰ رکورد رسید و کلی اطلاعات دیگر به سیستم اضافه شد. بعد از چند ساعت کار کردن با سرور، رم مصرفی کل سیستم (به جز cache) به ۴۴۰ مگابایت رسید ولی باز هم باورد کردنی نیست. یعنی خود لینوکس، جاوا، برنامه‌ها، بانک اطلاعات و خلاصه همه چیز، فقط ۴۰۰ مگابایت!!!

Screenshot from 2014-03-06 00:42:36

البته قبلاً با ۱ میلیون رکورد روی سیستم خودم (که آن هم لینوکس است) تست کرده بودم و باز هم سرعت باور نکردنی بود! ولی فکر نمی‌کردم با چنین سرور ضعیفی چنین پاسخی بگیرم.

همین تعداد رکورد را در SQL Server دارم. در حالتی که سر سرور خلوت است فقط ۸۰۰ مگابایت توسط SQL Server به تنهایی مصرف می‌شود! همیشه مجبور بودم یک سرور ویندوزی با حداقل ۴ گیگابایت رم تهیه کنم و برای SQL Server حتما از نسخه Standard یا Enterprise (نسخه‌های دزدی) استفاده کنم تا بتواند بیشتر از ۱ گیگابایت رم را استفاده کند و سرعت خوبی داشته باشد. خود ویندوز و دات نت و بقیه برنامه‌ها هم که بقیه رم را مصرف می‌کردند و تقریبا چیزی باقی نمی‌ماند.

Screenshot from 2014-03-06 00:50:07

متاسفانه بخاطر مسائل امنیتی تا کامل شدن کار فعلاً نمی‌توانم لینک وب سایت را منتشر کنم ولی به زودی این کار را خواهم کرد.

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

پردازش توزیع شده و غیر همزمان تصویر در MongoDB با Scala

MongoDB فایل‌های بزرگتر از ۱۶ مگابایت را به صورت تکه تکه شده ذخیره می‌کند. به هر کدام از این تکه‌ها یک Chunk می‌گویند. قوانینی که برای ذخیره و بازیابی فایل در MongoDB وضع شده GridFS نام دارد که توسط درایورهای MongoDB پیاده‌سازی می‌شود.

وقتی می‌خواهیم یک فایل را از MongoDB بخوانیم، فایل به صورت Chunkهایی از آرایه‌های بایت ارائه می‌شوند (Chunks of Arrays of Bytes). مثلاً یک فایل ۱۰۰ مگا بایتی در ۱۰۰ قطعه ۱ کیلوبایتی ارائه می‌شود.

چرا سازندگان روانی MongoDB این قانون را وضع کردند؟ MongoDB یک بانک اطلاعات است که از اول برای توزیع فیزیکی طراحی شده و ممکن است لازم باشد یک فایل بزرگ در بین ماشین‌های مختلف توزیع شود. و توزیع یک فایل ۱۰۰ مگابایتی سخت از توزیع ۱۰۰ قطعه یک کلیو بایتی است.

اگر هم نخواهیم فایل را در Mongo ذخیره کنیم و فقط مسیر فایل را در بانک ذخیره کنیم آن وقت اگر بخواهیم برنامه‌ را به صورت توزیع شده روی چند سرور اجرا کنیم مشکلات زیادی در Sync کردن فولدری که فایل‌ها را در آن‌ها نگهداری می‌کنیم خواهیم داشت. توجه کنید که ممکن است Sync دو طرفه باشد. اگر هم بخواهیم یک فولدر مرکزی Share شده برای فایل‌ها بگذاریم که دیگر سیستممان توزیع شده نیست!

تا اینجا خیلی مسئله پیچیده‌ای نبود. نکته مهم اینجاست که در برنامه‌نویسی غیر همزمان در هنگام خواندن یک فایل از Mongo ما نمی‌توانیم صبر کنیم تا تمام قطعات برسند و بعد آنها را به هم بچسبانیم و ارائه دهیم یا حرکتی روی آن‌ها بزنیم. بلکه با رسیدن هر قطعه به صورت Event-driven به ما اطلاع داده می‌شود و باید یک جوری قطعه‌ها را به هم بچسبانیم یا (از آن بهتر) روی همان قطعه کوچک کار کنیم و همان را به مصرف کننده پاس دهیم.

خوشبختانه در چارچوب Play امکانی فراهم شده که اجازه می‌دهد همانطور که MongoDB قطعه، قطعه فایل‌ها را به دست ما می‌رساند ما هم آنها را دست به دست به دست Browser کاربر نهایی برسانیم. کل ماجرا با جزئیاتش پیچیده‌ است ولی با کمک ویژگی‌های Scala واقعاً به راحتی انجام می‌شود. مفهومی وجود دارد به نام Iteratee (درکش کمی مشکل است ولی واقعاً کاربردی است) که با کمک آن این‌ قبیل کارها راحتتر انجام می‌شود.

اما یک مشکل دیگر وجود دارد؛ مثلاً فرض کنید یک فایل تصویری در MongoDB داریم که می‌خواهیم در لحظه (بعد از درخواست Browser) سایز آن را تغییر دهیم (از آن Thumbnail بسازیم). قبلاً اکثر ما بارها در #C آن را انجام دادیم و کتابخانه‌های مکفی برای اینکار وجود دارند. فایل تصویر را می‌خوانیم، (در قالب Stream یا آرایه‌ای از بایت) به کتابخانه Image Resizer محبوبمان می‌سپاریم و تصویر Resize شده را تحویل می‌گیریم بعد آن را با HTTP به سمت Browser می‌فرستیم. جداً کار سختی نیست. مثل شکل زیر:

پردازش خطی

ولی من نمی‌خواهم یک فایل کامل را به یک کتابخانه بدهم تا آن را تبدیل به یک تصویر کوچکتر کند. همانطور که گفتم نمی‌توانم (نباید) صبر کنم تا فایل کامل شود و بعد به سراغ Resize کردن بروم. بلکه وقتی اولین قطعه از فایل (که ممکن است مثلاً ۱ کیلوبایت باشد) به دستم برسد باید شروع به محاسبات تغییر اندازه کنم و منتظر قطعه بعدی نباشم و تا همینجای کار را برای مصرف کننده ارسال کنم. به این ترتیب هم حافظه کمتری مصرف می‌کنم هم در زمان ترافیک بالا خیلی خیلی کمتر از منابع سیستم استفاده خواهم کرد. ولی این واقعاً پیچیده است؛ در مایه‌های فیلم‌های عملی تخیلی! مثل شکل زیر:

پردازش قطعه قطعه

نمی‌دانم الگورتیمی وجود دارد که بتواند به صورت تکه تکه (نه از نظر تصویر بلکه از نظر محتوی فایل) یک فایل تصویری را Resize کند؟ اصلاً نمی‌دانم فرمت‌های تصویری مرسوم (Jpeg، Gif و …) قابلیت پردازش به این شکل را دارند یا نه؟

ولی سعی کردم؛ در گروه ReactiveMongo یک پست ارسال کردم وتقاضای کمک کردم. اگر این کار ممکن باشد تاثیر به شدت زیادی در Preformance وب سایت‌هایی که با این روش ساخته می‌شوند خواهند داشت و پاسخگویی سرور به تعداد بالای کاربر به شدت افزایش پیدا می‌کند.

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

برای حسن ختام، این یک قطعه کد بر روی چارچوب Play و زبان Scala است که یک فایل Zip را در همان زمان تولید، خرد خرد به کلاینت ارسال می‌کند (صبر نمی‌کند که اول فایل ایجاد شود و در آخر آن را ارسال کند).

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

توضیح: تصاویر این پست توسط نرم‌افزار LibreOffice Draw و با بی دقتی بسیار اما به راحتی ساخته شده است. لطفاً اگر از Microsoft Visio استفاده می‌کنید و نمی‌توانید آن‌ را بخرید (کپی رایت را رعایت نمی‌کنید)، از LibreOffice Draw استفاده کنید.

چطور Scala و Play Framework را یاد می‌گیرم

یکی از خوانندگان وبلاگ (رضا) در مورد منابعی که برای یادگیری Scala و Play Framework استفاده کردم سوال کرد. متن زیر بیشتر شبیه یک سفرنامه است تا لیست منابع اما امیدوارم منابعی هم از آن قابل استخراج باشد 🙂

از آنجایی که من پیش زمینه دات نتی دارم شاید این روندی که من پیش گرفتم برای کسانی که پیش زمینه‌های متفاوت دارند کارساز نباشد.

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

بعد با کتاب Scala in Action شروع کردم که شاید انتخاب خیلی خوبی نبود ولی خواند تقریباً نیمه اول کتاب کمک خوبی بود و بقیه آن را نخواندم. شاید اگر الان آن را مطالعه کنم خیلی بهتر بفهمم. پیشنهاد می‌کنم اگر بخش‌هایی از این کتاب (یا کتاب مشابه) را متوجه نشدید به راحتی از کنارش عبور کنید و ادامه دهید.

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

مقایسه‌ها خیلی کمک می‌کند. مثلاً در اینجا معادل Extension متدهای مرسوم در #C برای Scala گفته شده.

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

مرحله بعد شروع ساخت یک برنامه واقعی خیلی ساده بود. من نیاز به یک Time-sheet آنلاین داشتم که آنرا با Scala، Play و MongoDB شروع کردم و خیلی چیزها هم یاد گرفتم اما به علت مشغله کاری نیمه کاره رهایش کردم 🙂 باشد که در فرصتی مناسب در Github بارگذاری کرده و ادامه دهم.

برای یادگیری Play Framework هنوز هیچ کتابی نخواندم ولی یک نگاه مختصری به کتاب Play for Scala انداختم و متوجه شدم که تقریباً همان مستندات خود سایت www.playframework.com است. مستندات Play مختصر و مفید هستند. در عرض چند دقیقه اولین برنامه‌تان با Play را می‌نویسید.

بدون شک بعد از یادگیری Scala و مطالعه مستندات Play Framework (از سایت خودش) و نوشتن برنامه‌های ساده با Play و Scala، بهترین منبع برای حرفه‌ای شدن در Play خواندن سورس‌کدهای آن در Github است. باور کردنی نیست که چقدر این کدها مختصر و مفید و تمیز و خوانا هستند. اولین بار است که برای فهمیدن اینکه یک متد از یک کتابخانه (که خودم ننوشتم) چکار می‌کند، ترجیح می‌دهم سورس آن را ببینم تا به مستنداتش رجوع کنم. بی دلیل نیست که خود Play هم برنامه‌نویسان را تشویق به مطالعه سورس‌ها و نوشتن کدهای مشابه می‌کند.

نکته اینکه؛ با وجود اینکه Play با زبان Scala نوشته شده است فقط برای Scala نیست و یک API مجزا مخصوص Java دارد که من فقط بر روی نسخه Scalaی آن تمرکز دارم.

برای من یکی از جالب‌ترین نکات بعد از مهاجرت به متن باز، وجود Community قوی و انرژی که افراد قدیمی برای یک فرد تازه وارد صرف می‌کنند است. وقتی جواب سوالی را پیدا نمی‌کردم آن را در Google Group مربوطه می‌پرسیدم که همیشه با توجه و کیفیت عالی و سرعت خوب پاسخ گرفتم؛

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

برای درک قدرت Community اشاره می‌کنم به یک سوال و جواب وحشتناک جالب در اینجا؛ یک بنده خدایی دنبال یک Wrapper با زبان Scala بر روی کتابخانه‌ای برای کار با Excel است. یک نفر پاسخ می‌دهد که یک API جالب ساخته ولی نمی‌داند رییسش اجازه می‌دهد کد را با دیگران به اشتراک بگذارد یا خیر. در این فاصله یکی از بچه‌ها API مربوطه را پیاده‌سازی کرده و در Github در دسترس عموم قرار می‌دهد.

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

و در نهایت شرکت در برنامه آموزشی Coursera بود که در موردش نوشته بودم و واقعاً‌ بهترین تجربه من در شرکت در یک برنامه‌ آموزشی تا کنون است که یک ساعت از آن می‌ارزد به تمام دوران دانشجویی که داشتم. البته این برنامه آموزشی بیشتر در مورد نحوه طراحی و نوشتن برنامه‌های Reactive است. مطلبی در خصوص Play در این برنامه تدریس نمی‌شود.

به طور خلاصه نه فقط برای Scala بلکه برای هر تکنولوژی دیگر که تازه می‌خواهم یادش بگیرم مراحل زیر را طی می‌کنم (تا کنون جواب خوبی گرفتم)؛

  1. مطالعه خیلی سریع و کلی صفحاتی مثل ویکی پدیا در مورد تکنولوژی مورد نظر
  2. آشنایی با سازندگان یا پشتیبانان تکنولوژی و سوابق کاری ‌آنها
  3. خواندن یک یا چند کتاب خوب (حتی نصفه و نیمه)
  4. دست به کار شدن و ساختن اولین برنامه
  5. عضویت خوراک وبلاگ‌ها و وب‌سایت‌های مرتبط
  6. سوال و شرکت در بحث‌های Community
  7. شرکت در Courseهای آنلاین

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