استخراج آمار تکنولوژی‌های برنامه‌نویسی از نظر سنجی جادی

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

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

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

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

زبان‌های برنامه‌نویسی مورد استفاده شما در پروژه‌ها کدامند؟

iran_programming_languages_stat

به جز زبان‌های فعلی‌تان، دوست دارید با چه زبان برنامه ای نویسی کار کنید؟

iran_programming_languages_interested

دیتابیس‌های مورد استفاده؟

iranian_db

سیستم عامل رومیزی شما کدام است؟

iranian_os

سیستم عامل سرور مورد علاقه شما

iranian_os_server

در چه محیطی برنامه نویسی می‌کنید

iranian_ideاینها آماری بودند که رسم نمودار ازشون بدون استفاده از این برنامه سخت بود.

ابزارهای استفاده شده برای تهیه این پست:

  1. Scala
  2. Git
  3. LibreOffice Calc
  4. Gimp

اندر باب سیستم توزیع بن کتاب نمایشگاه کتاب ۹۵

امسال هم مثل پارسال فروش بن دانشجویی از طریق سیستمی که با Scala و MongoDB پیاده کرده بودم انجام شد. البته کلی کار جدید و قسمت‌های دیگه مثل بن‌های اساتید و مهد کودک و … هم بهش اضافه شد و یکی از دوستام هم کمکم کرد و بالاخره طلسم تک نفری بودن پروژه شکسته شد. از همه اینها مهمتر نحوه پرداخت بود که برای اولین بار به جای درگاه پرداخت آنلاین یا همون IPG از طریق نرم‌افزار آپ انجام شد.

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

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

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

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

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

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

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

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

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

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

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

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

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

و برای حسن ختام برنامه یه ماجرای آموزنده از همین بانک شهر میگم؛

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

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

کاش کمتر حرف پوچ میزدیم و بیشتر عمل میکردیم.

 

چه زمانی اسکالا مناسب نیست و چه زمانی مناسبه؟

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

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

قبل از هرچیزی باید بگم که اضافه شدن لامبدا به جاوا ۸ فقط یک قدم برای نزدیک‌تر کردن جاوا به اسکالا بوده و خیلی امکانات دیگه هست که فعلا توی جاوا پشتیبانی نمیشه و اگر با اسکالا کار کرده باشید، باز هم کار با زبون جاوا براتون سخته. امکاناتی مثل Type-safety واقعی، Immutability، Pattern Matching و … چیزهایی هستند که توی دنیای امروز تبدیل به یه نیاز حیاتی شدن. شاید یه مقداری از اینها رو بشه توی جاوا شبیه‌سازی کرد ولی کار اضافه‌تر میبره و از اون مهمتر هنوز توی فرهنگ زبون جاوا جا نیفتاده. در حالی که اینها جزو فرهنگ اسکالاست و برنامه‌نویس اسکالایی وجود نداره که اینها رو ندونه.

خوشبختانه دانشگاه‌های برتر دنیا مثل دانشگاه‌های ایران نیستند و واقعا علم کاربردی تولید میکنن. بحث کامپایلرها و زبان‌ها هم مستثنا نیست و پیشرفت‌های خیلی زیادی توی ۴۰ سال اخیر داشتند. این پیشرفت‌ها توی بعضی از زبون‌های برنامه‌نویسی مثل اسکالا و راست (Rust) نمود پیدا کرده و بعضی از زبون‌های جدید مثل گو تقریبا این ۴۰ سال رو نا دیده گرفتن، در عوض سازنده‌هاش بیشتر از هر چیزی روی مولد بودن و کارایی بیشتر برنامه‌نویس و راه افتادن سریع برنامه‌نویس‌های مبتدی تاکید کردن. به عبارت دیگه تمرکزشون روی غیر حرفه‌ای‌هاست که البته بیشتر جامعه رو تشکیل میدن.

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

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

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

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

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

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

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

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

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

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

اما از نظر حرفه‌ای اسکالا می‌تونه چه تاثیری توی زندگی شغلی یه برنامه‌نویس بذاره؟

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

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

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

خلاصه

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

مهاجرت به آرچ

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

نصب

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

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

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

Pacman

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

به نظر من کل آرچ خلاصه شده توی Pacman که البته ارزشش رو هم داره.

محیط‌های دسکتاپ (Desktop)

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

واسه همین من از بین محیطهای دسکتاپ Gnome، KDE و Xfce رو نصب کرد تا ببینم کدوم بهتره.

Xfce

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

چون قبلا LXDE رو دیده بودم دیگه اون رو نصب نکردم، تقریبا تو مایه‌های Xfce هست فقط بازم سبکتره.

Gnome

نسخه ۳ گنوم به نظر اصلا جالب نیست. بدترین ویژگیش اینه که از فضا خیلی بد استفاده کرده در حالی که ادعا میکنه مناسب برای تبلت هست. یه نوار که ۸۰ درصدش بیخودیه اون بالا همیشه هست. وقتی یه برنامه رو Full-screen کنی یه نوار بیخود دیگه اضافه میشه که فقط اسم برنامه توشه، یه نوار دیگه برای منو هم هست. کل اینها شاید نزدیک ۲۰٪ صفحه رو میگیره که واقعا تو مخه. برعکس Unity که واقعا عالی از فضا استفاده میکرد.

برای هر کاری باید یه پلاگین نصب کرد که یا دیگه ساپورت نمیشه یا باگ داره. ظاهرش رو دوست دارم اما بقیه چیزاش به دلم نشست.

KDE

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

اما اصلا Stable نبود. وقتی سیستم برای مثلا ۱۵ دقیقه بیکار میموند بعد از لاگین دوباره، هر چند ثانیه یکبار هنگ میکرد.

حالا نمی‌دونم کاملا اوکی شده یا نه ولی بعد از اینکه بسته xf86-video-ati رو حذف کردم فعلا انگار درست شده و مشکلی ندارم.

یکی از مسائل دیگه اینه که مثلا Variety روی KDE درست کار نمیکنه. میشه یه کارایی کرد ولی بعضی وقتا قاطی میکنه و دوباره تصویر پیشفرش دسکتاپ رو نشون میده.

نتیجه

خلاصه که آرچ خیلی باحاله و نقطه منفی در مورد آرچ ندارم بگم. اما در مورد محیطهای دسکتاپ، به نظرم هنوز Unity بهترین استفاده رو از فضا داره میکنه و واقعا Stable هست. اما KDE Plasma واقعا عالیه. هنوز نمی‌تونم بگم Plasma 5 بهتره یا Unity ولی حداق جهت تنوع هم که شده Plasma 5 خیلی داره حال میده.

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

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

ترافیک لحظه‌ای روی گوگل مپ

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

google_map_tehran_traffic

نکته اینجاست که گوگل چطور می‌تونه ترافیک یه شهر که هیچ دسترسی بهش نداره رو به دست بیاره؟ کاری که شهرداری همین شهر به راحتی و برای کل شهر نمی‌تونه انجام بده.

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

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

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

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

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

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

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

 

دوره آموزشی رایگان توسعه REST API با Play Framework نسخه Java

rayan_free_courseشرکت رایان هم افزا داره یه دوره رایگان آموزشی با زبان Java و چارچوب Play و Spring برگزار میکنه. فرصت خوبی برای کسانی هست که با زبان Java آشنا هستند و می‌خوان یه پیشرفت اساسی توی این زبان و چارچوب‌های مدرن داشته باشن.

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

برای دریافت اطلاعات بیشتر کد QR رو اسکن یا به اینجا مراجعه کنید.

 

 

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

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

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

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

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

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

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

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

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

خودآموز اسکالا در Udemy

امروز یه نفری از Udemy به زبان انگلیسی به من ایمیل زد که شما توی وبلاگت لینک دادی به Scala School و ما در Udemy اومدیم یه منبع جدید درست کردیم که میتونه یه مکمل خوب باشه برای یادگیری اسکالا در کنار بقیه منابع. حالا خواسته بود اگر کارشون خوبه، توی این وبلاگ معرفیش کنم. به نظر من که خیلی زحمت کشیدن و خیلی میتونه توی یادگیری اسکالا کمک کنه. در عین مختصر بود خیلی مفید و کاربردیه.

با افتخار، آدرس این منبع هست: https://blog.udemy.com/scala-tutorial-getting-started-with-scala

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

خلاصه که کارشون درسته، دمشون گرم. اگر می‌تونید حمایتشون کنید.

 

مقایسه تجربی روبی، جاوا اسکریپت و اسکالا

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

بیشتر کار من با روبی روی Ruby on Rails، با جاوا اسکریپت روی AngularJS و با اسکالا روی Play Framework بوده.

شروع یادگیری

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

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

کتابخانه‌ها

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

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

روبی هم از نظر تعداد و هم از نظر کیفیت کتابخونه‌های خوبی داره. فکر کنم بین این سه تا بهترین باشه.

کامیونیتی

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

به نظر من کامیونیتی اسکالا حرف اول رو میزنه و سطح خیلی خیلی بالایی داره.

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

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

راحتی و سرعت در تولید

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

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

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

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

نگهداری و تغییر کد

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

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

تست اتومات و دیباگ

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

چارچوب Rails قوی‌ترین و راحتترین امکانات تست رو داره. فکر همه چیز رو کردن و در کمترین زمان و با بهترین کیفیت میشه برای هر قسمت از برنامه و در هر سطحی (Unit یا Functional) تست نوشت. برای دیباگ هم، هم میشه از امکانات IntelliJ به راحتی استفاده کرد هم Gem ی مثل ByeBug واقعا دیباگینگ رو برای آدم لذت بخش میکنه.

ابزارهای تست جاوا اسکریپت زیاد قوی نیست و مخصوصا دیباگ کردن واقعا عذاب آوره. حتی console.log هم خیلی از جاها کار نمیکنه. AngularJS سعی کرده از اول کار تست رو راحت کنه ولی فقط Unit Testing رو راحت کرده و Integration Test به سختی و به کندی قابل انجام هست و اصلا لذت بخش نیست. دیباگینگ Integration Test توی Angular یکی از رنج آور ترین کارهای عالمه.

تست توی اسکالا به اندازه روبی راحت نیست ولی واقعا لذت بخشه و جزیی از سیستمه. از روز اول هم فکرش شده بوده و چیزی نیست که بعدا به سیستم اضافه شده باشه. IntelliJ هم که مثل بنز ازش پشتیبانی میکنه و دیباگینگش فوق العاده قویه. از اونجایی که اسکالا Static-type هست، وقتی برای یه نرم‌افزار تست بنویسی دیگه کاملا خیالت راحته که همه چیز اونطور که باید پیش میره و نیازی نیست به اندازه زبونهای دینامیک تست‌های واضح و مبرهن بزنی.

 ابزارهای توسعه (IDE)

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

به هر حال ساختن ابزارهای کمکی برای توسعه زبان دینامیک کلا کار سختیه و بعضی جاها غیر ممکنه.

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

سرعت اجرا

واضحه که اسکالا از همه سریعتره و چارچوب Play بالاترین کارایی رو داره. هم از نظر سرعت و از نظر مقیاس پذیری (Capability). حتی چارچوب‌های وب Rust، Go و بقیه زبون‌ها هم توی تست‌هایی که روی لپ تاپ خودم گرفتم نمیتونن به پای Play برسن.

بازار کار

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

وضعیت نیروی انسانی

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

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

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

نتیجه گیری

نتیجه گیری نداریم! با هر زبونی که حال میکنید کد بزنید.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

به روز رسانی:

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

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

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

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