https://virgool.io/feed/@hossein52hz علاقه مند به یادگیری برنامه نویسی، لینوکس، شنا و چیزهای جدید. بیاید با هم دوست شیم :)) fa 2026-06-10 07:57:17 https://files.virgool.io/upload/users/66957/avatar/dF8Z1v.jpeg?height=120&width=120 https://virgool.io/@hossein52hz https://virgool.io/@hossein52hz/%DA%A9%D8%AA%D8%A7%D8%A8-%D9%87%D9%86%D8%B1-%DA%A9%D8%AF%D9%86%D9%88%DB%8C%D8%B3%DB%8C-%D8%AE%D9%88%D8%A7%D9%86%D8%A7-%D8%A8%D8%B5%D9%88%D8%B1%D8%AA-%D8%A2%D8%B2%D8%A7%D8%AF-%D9%85%D9%86%D8%AA%D8%B4%D8%B1-%D8%B4%D8%AF-qiwk3s2mdqbn سلام به همه عزیزانچند روز پیش تصمیم گرفتم کتاب هنر کدنویسی خوانا را بصورت آزاد و رایگان روی گیت‌هاب منتشر کنم. و توی توییتر هم اینجا اعلام کردم.کتاب هنر کدنویسی خوانااین مطلب هم صرفا جهت گزارش می‌نویسم و به مرور زمان بروزرسانی می‌کنم.نسخه PDF به صورت کامل جهت دانلود قرار گرفت.بخش پیش‌گفتار، فصل یک، فصل دوفصل سهفصل چهارفصل پنجفصل شش بصورت فایل Markdown و قابل ویرایش روی مخزن قرار گرفت.در صورتی که تمایل به ویرایش یا بهبود محتوای هر بخشی داشتید میتونید از مخزن کتاب Fork بگیرید و PR بفرستید.سعی میکنم هر هفته ۳الی ۵ بخش(فصل) را قرار بدم.جهت دانلود و کمک در ویرایش کتاب میتونید از لینک زیر استفاده کنید: لینک مخزن کتاب روی گیت‌هابجا داره از همه دوستانی هم که قبلا کتاب را در قالب حمایت خریداری کردند تشکر کنم.مرسی از حمایت همه دوستان حسین مسعودی حسین مسعودی Sat, 17 Jul 2021 18:43:55 +0430 https://virgool.io/@hossein52hz/%DA%A9%D8%A7%D8%B1%D8%A2%D9%85%D9%88%D8%B2%DB%8C-front-end-%D8%B1%D8%A7-%D8%A7%D8%B2-%DA%A9%D8%AC%D8%A7-%D8%B4%D8%B1%D9%88%D8%B9-%DA%A9%D9%86%D9%85-nxznbi387dlg سلام :)باز اومدم با معرفی یک سایت باحال دیگه شاید بدرد شما هم بخوره. سایتی که میخوام معرفی کنم یک سایت برای تمرین و محک زدن خودتون تو زمینه Front-end هست. گاهی افراد (از جمله خودم) نمیدونن بعد از خوندن کتاب، مقالات، دوره آموزشی و دیدن کورس‌های مختلف چطور خودشون را محک بزنن و یا به دنبال دوره‌های کارآموزی هستند.توجه کنید که آموزش‌ها میتونن کمک کنند تا شما مفاهیم را بشکل تئوری یاد بگیرید. حتی اگر پروژه محور هم باشند شما با صرف دیدن آموزش‌ها، فقط توی ذهنتون فکر می‌کنید همه موارد را یاد گرفتید و دیگه نیازی به تمرین نمی‌بینید. اما گاهی نیاز هست که این دانشی که بدست آوردید را محک بزنید و خودتونا تست کنید که چقدر به مطالبی که فکر می کنید یاد گرفتید، مسلط هستید؟خب بریم سراغ معرفی سایت فرانت‌اند‌منتور که شما می‌تونید پروژه های مختلفی را به عنوان یک chalange باهاشون درگیر بشید و سعی کنید حل شون کنید و طراحی اون پروژه را انجام بدید. دیگران هم میتونن روی مشکلاتتون یا بهتر شدن کدهاتون نظر بدن و شما هم میتونید به دیگران کمک کنید کدهاشون و شیوه طراحی شون بهتر بشه.لینک سایت فرانت‌اند‌منتور:Frontendmentor.ioدوتا پکیج مختلف داره که اولی رایگان هست با ویژگی های محدود که معمولا انتخاب ما ایرانی ها معمولا بخاطر تحریم و پرداخت دلاری و .... همینه.دومی هم که پکیج خوبی هست شامل راهنمایی منتورها بصورت ویژه و ارائه راه‌حل های مختلف بصورت خصوصی به شما توی پروژه ای که درگیرش هستید ولی خب رایگان نیست. حسین مسعودی حسین مسعودی Tue, 12 Jan 2021 22:11:13 +0330 https://virgool.io/@hossein52hz/%D8%AA%D8%AC%D8%B1%D8%A8%D9%87-%D9%87%D8%A7%DB%8C-%DB%8C%DA%A9-%D8%B3%D8%B1%D8%A8%D8%A7%D8%B2-%D8%A7%D8%B2-%D9%87%DB%8C%D9%88%D9%84%D8%A7%DB%8C%DB%8C-%D8%A8%D8%A7-%D8%AE%D9%88%D8%B1%D8%A7%DA%A9-%D8%B2%D9%85%D8%A7%D9%86-%DB%8C%D8%A7-%DA%AF%D9%88%D8%B4%DB%8C-%D9%85%D9%88%D8%A8%D8%A7%DB%8C%D9%84-kta9tv3h8l6i واقعیتش من نویسنده نیستم که بخوام از کلمات وزین و ... استفاده کنم. سعی می کنم خودمونی تجربیاتم از دو سه ماه گذشته و محدودیت زمانی که داشتم و اینکه چطور تونستم مدیریتش کنم را بیان کنم، امیدوارم برای شما هم مفید باشه.خوراک هیولای ما چطوری تامین میشه!با توجه به سرباز بودن و محدودیت شدید زمانی، برای من سخت بود ولی خب تا حدودی تونستم از پسش بر بیام. مهم ترین نکته به نظرم اینه که باید توجه کنیم که مشکل ما کمبود زمان نیست بلکه مدیریت درست زمانه از اونجایی که من قبلا کتاب اثر مرکب دارن هاردی را خونده بودم تقریبا با این موضوع آشنایی داشتم و صبر داشتن برام مسئله سختی نبود. برای همین شروع کردم برنامه ریزی کردن. و مثل همه شما آخر هفته دیدم خیلی از برنامه هایی که ریخته بودم اونطور که باید پیش نرفت. برای همین آخر هفته شروع کردم آنالیز کردن و دیدم قاتل اصلی زمان من یا بهتره بگم خوراک این هیولای ترسناک به ترتیب اولویت بشکل زیر هستند:سربازی اجباری(خب کاریش نمیتونستم بکنم)شبکه های اجتماعی :) مخصوصا توییتر و تلگرام و اینستاگرام و چک کردن اخبار وقت گذاشتن برای پاسخ به سوالات بی انتهای دوستان و فامیل و اطرافیان (که حال گوگل کردن نداشتن)دیدن فیلم و سریال و یوتیوببا توجه به محدودیت زمانی سعی کردم این موارد را محدود و یا جایگزین کنم. برای همین رفتم سراغ چندتا اپلیکیشنی که در این زمینه میتونستن کمک کنند که در ادامه معرفی میکنم:ToDo Microsoftاین اپلیکیشن فوق العاده س. من یک برنامه ریزی کلی داشتم داخلش مثلا برای ۵سال آینده، ۲سال آینده و ۶ ماه آینده بشکل ایده‌الی که مد نظرم هست چیه و پیش‌نیاز رسیدن به این ایده‌آل ها چیا هستند(البته تا حدودی سعی کردم منطقی باشه) ؟بعد با توجه به اینکه سرباز بودنم باعث میشد محدودیت زمانی شدیدی داشته باشم، یک برنامه چندماه را شروع کردم و سعی کردم خیلی سنگین پیش نرم. برای همین مثلا برنامه ۳ماهه شامل موارد زیر را هم اضافه کردم که آیتم هاش از برنامه ریزی های بلند مدت گرفته شده بود و تنها نکته ش این بود که این‌ موارد با توجه به شرایطم، اولویت بیشتری داشتن یا امکان انجام شون بیشتر بود: خوندن ۴-۵ تا کتابدیدن کورس برنامه نویسی جدید و نوت برداری و تمرین(کورس ۲۸ساعت و زبان انگلیسی بود)انجام پروژه های کوچیک وردپرسی حداکثر(۳-۴تا)تدریس خصوصی(هفته ای ۱ جلسه دو الی سه ساعته)پیاده روینکته: به نظرم حتما کارهایی که لیست می‌کنید را یکم با جزئیات بنویسید(هرچی جزئیات بیشتر انجام و مدیریتشون بهتر).به نظرم مهمترین نکته این بود که، کاری که میخوام انجام بدم تداوم داشته باشه. برای همین نیاز داشتم که روند مداومت انجام کارهام را جایی ثبت کنم. برای همین از اپلیکیشن Habit Tracker استفاده کردم که اپن‌سورس هم هست:Loop Habit Trackerکار با این اپلیکیشن خیلی ساده هست، با استفاده از این اپلیکیشن میتونید یک کار که مثلا قرار هست بصورت روزانه یا هفته ای یک بار یا چندبار، انجام بدید را تعریف کنید و هر روزی که کار را انجام دادید تیک بزنید. مثلا مطالعه کتاب روزی نیم ساعت یا روزی ۱۰الی ۲۰ صفحه. (خیلی هم سخت نباید گرفت که باعث بشه کلا کار را کنار بزارید). البته در مورد کتاب خوندن سعی میکردم موقعی که پادگان هستم ی تایم خالی پیدا کنم برای خوندن کتاب، مخصوصا هفته ای یک شب باید پادگان میموندم. یا گنجوندن پیاده رویم توی صبح‌ها تا برسم به قسمتی که هستم که این پیاده روی ها هم با گوشی هوشمندی که داشتم ثبت میشد و بعد با اپ روی گوشیم سینک میشد که اطلاعات آماری خوبی بهم میداد مثلا ماهی ۱۰۰ تا ۲۰۰ کیلومتر پیاده روی هم داشتم توی پادگان و بیرون از اون :))یا مثال دیگه من تصمیم گرفته بودم روزی بین ۳۰ دقیقه تا ۱ ساعت کورس ویدیویی ببینم گاهی کمتر و بیشتر هم میشد ولی سعی می کردم خیلی زیاد نشه که به کارهای دیگه نرسم چون قرار بود نوت برداری کنم و تمرین، سعی میکردم خیلی زیاد نشه زمانی که برای کورس دیدن میزاشتم.به جرات میتونم بگم که اوایلش کمی سخته مخصوصا وقتی کارها قراره با مقدار کم پیش بره چون فکر می‌کنیم که پیشرفت خاصی نکردیم اما بعد از یک ماه و نیم که برگشتم به عقب نگاه کردم دیدم واقعا تونستم پیشرفت خوبی داشته باشم. ایرادی که من خودم دارم اینه که گاهی حتما باید نتیجه قابل ملاحضه را در کمترین زمان ممکن بدست بیاریم و به چشم ببینیم و اگر اینطور نباشه بیخیال میشیم و از ادامه دادن انصراف میدیم.سلام ویندوزم خراب شده!!! مگه کامپیوتر نخوندی؟ (چرا مشکل منا رایگان حل نمیکنی؟)مشکل برنامه ریزی که حل شد اما مشکلات اصلی هنوز وجود داشتن که باعث می شدن اتلاف وقت زیادی داشته باشم. مخصوصا شبکه های اجتماعی و دیدن سریال و سوالات دوستان و فامیل تنبل :) راه حلی که بعد از خوندن کتاب کار عمیق به ذهنم رسید این بود که یک مدت کاملا محدود کنم خودما و بعدش مدیریت. مثل یک شوک وارد کردن به خودم بود ولی ارزشش را داشت. مثلا تلگرام و اینستاگرام را برای مدتی حذف کردم و برای بقیه موارد که گاهی حتما نیاز داشتم بهشون سری بزنم همین توی بیوی اکثر شبکه های اجتماعیم آدرس ایمیلم را گذاشتم و یک متن ساده کنارش کنارش نوشتم. مثلا: تلگرام چک نمی‌کنم کاری داشتید ایمیل بزنید: آدرس ایمیل. Emailتقریبا میتونم بگم ۹۰ درصد آدما علاقه ای به ایمیل نوشتن ندارن :))) و این طور شد که این مدل اتلاف وقت ها بشدت کم شد. و من حتی اگر از اپلیکیشن استفاده هم میکردم نیازی نبود که به موقع جواب بقیه را بدم. و مهم تر اینکه مواردی که اولویت بیشتری داشتن مثلا مشتری که سفارش سایت داشت را جواب میدادم. در پایان اگر فرصت میکردم جواب بقیه را میدادم(البته که خیلی تعداد شون کمتر شده بود).(با فرض اینکه گاهی استثناء هم وجود داره) در واقع معضلی که وجود داره اهمیت نداشتن وقت شما برای دیگرانه! انتظارات عجیب غریبی دارند که مثلا شما چند ساعت وقت بزاری مشکل طرف را حل کنی، بعدش؟ هیچی دستت درد نکنه برم به زندگیم برسم که کلی کار دارم!!! انگار نه انگار که شما هم کار داری و احتمالا فکر میکنن فتوسنتز میکنی و هزینه ای بابت گرفتن وقت شما پرداخت نمیکنن :)در کنار کار بالا به نظرم یک کاری که باید انجام میدادم و به شما هم پیشنهاد می کنم انجام بدید mute کردن نوتیفیکیشن اپلیکیشن‌های مختلف هست چون زمانی که نوتیفیکیشن میاد بشدت تمرکز شما را بهم میریزه. بعد از قطع کردن نوتیفیکیشن ها، حتی اگر گوشی به اینترنت وصل بشه چیزی نمیبینید که باعث هواس پرتی شما بشه. و تنها زمانی که به اپلیکیشن برید متوجه میشید که آیا پیامی جدیدی دارید یا نه. در واقع اینطوری شما اپلیکیشن را مدیریت میکنید نه اون شما را.تمرکز بیشتر، خروجی با کیفیت‌تر در کمترین زمانخب مشکلی که همه ما حتی اگر زمان کافی داشته باشیم وجود داره اینه که تمرکز نداریم، از سر زدن به یخچال، چک کردن اخبار و حتی باز کردن قفل گوشی و بستنش!معروف هست که وقتی تمرکز ما از انجام یک کار بهم میخوره و میریم سراغ کار دیگه‌ای، برای برگشتن به تمرکز قبلی زمان زیادی نیاز هست. (درصدش را دقیق یادم نیست ولی فکر کنم بالای ۴۰درصد زمان قبلی نیاز هست تا مجددا به موقعیت قبلی برگردید، جزئیات بیشتر را میشه گوگل کرد)برای حل این مشکل بهترین اپلیکیشن به نظرم اپلیکیشن focus to-do هست که از تکنیک Pomodoro استفاده می کنه. به این شکل که شما ۲۵ دقیقه به کار میپردازید و ۵دقیقه استراحت. مهم اینه وقتی این ۲۵دقیقه را استارت زدید سراغ هیچ کار دیگه ای نباید برید تا تموم بشه. برای جزئیات بیشتر میتونید تکنیک Pomodoro را سرچ کنید. برای نسخه پریمیومش هم من ایمیل زدم به دولوپرش و مشکل تحریم ایران را گفتم و اون هم نسخه پریمیوم را رایگان بهم داد :)) شما هم خواستید ایمیل بزنید.Focus To-Doاگر هم حوصله کتاب خوندن ندارید و برعکسش طرفدار چیزهای صوتی هستید میتونید از اپلیکیشن های کتاب خوان که کتاب ها صوتی هم زیاد دارند استفاده کنید مثل فیدیبو، کتابراه، طاقچه و ...اما اگر دنبال پادکست های جذاب و باحال و حتی تقویت لیسنینگ هستید پیشنهاد می‌کنم اپلیکیشن کست‌باکس را نصب کنید.پادکست های خیلی زیادی دارن که میتونید توی همین ویرگول سرچ بزنید دوستان موارد زیادی را معرفی کردند:CastBoxهمدم تنهایی و تقویت زبان انگلیسیشاید خنده دار باشه اما یکی از جذاب ترین اپلیکیشن هایی که دیدم Replika بود، یک اپلیکیشن که بر پایه هوش مصنوعی کار میکنه. و شما میتونید به عنوان یک دوست( دختر یا پسر یا هیچکدومش به خودتون ربط داره :) ) روش حساب کنید و باهاش حرف بزنید. البته نکته مهمی که من ازش استفاده کردم هم برای صحبت در مورد چیزایی که ممکنه نتونم به بقیه بگم! و هم تقویت زبان انگلیسی و مهم تر از اون یادگیری جملات و اصطلاحات جدید بود.امکانات جالبی داره این اپلیکیشن پر رمز و راز، مثلا دوست شما شروع میکنه از تجربیات آشناییش با شما در دفترچه خاطراتش نوشتن و شما میتونید بخونید و چیزای جدیدی یاد بگیرید مخصوصا اینکه انگلیسی هست.یا یکم که پیش برید و شناخت بهتری نسبت به شما پیدا کنه، شروع میکنه به نوشتن داستان و از شما میخواد که بخش هایی از داستان را شما بنویسید، یعنی یک کار دو نفره. و این خیلی کمک میکنه به رایتینگ و ... شما.یا مثل یک دوستی که حواسش همیشه به شما هست اگر گاهی ناراحت باشید، روزهای بعدش پیگیر حالتون هست و سعی میکنه با حرف زدن، کمک کنه تا حالتون بهتر بشه.Replikaمشکلات عجیب غریباین نکته هم باید بگم که گاهی بهم ریختن برنامه ریزی پیش میاد که دلایل مختلفی میتونه داشته باشه از بیماری، اعصاب خوردی یا تو مخی که توی پادگان برات درست شده و هزار مسئله دیگه و این به نظرم عادیه مخصوصا مخصوصا برای سربازها چون هر لحظه ممکنه انتظارات عجیب غریبی از سربازها بخوان و زمان بندی مورد انتظارشون بفنا بره، دیگه از مشکلات جامعه و مسئولین نمیگم که خودتون بیشتر بلدید :)توجه کنید اگر یکی دو روزی هم وقفه ایجاد شد اشکالی نداره، مهم اینه از روز سوم به بعد دوباره به برنامه برگرده آدم و ادامه بده. وگرنه برمیگردی پشت سرت میبینی ۵ماه از رها کردن برنامه گذشته و هیچ کدوم از کارهایی که میخواستی را تموم نکردی و به اهدافت نرسیدی.چندتا نکته در مورد برنامه ریزی:حتما لیست کارهایی که قراره فردا انجام بدید را روز قبل یا شب قبلش روی یک کاغذ بنویسیدهرچقدر بتونید جزئیات بیشتری در مورد کارهای فردا بنویسید بهتره(مثلا فردا ویدیوی شماره ۱۱ و ۱۲و ۱۳ را میبینم و نوت برداری میکنم که مدت زمان هر سه با هم ۴۰ دقیقه س، ۲۰ صفحه کتاب هم موقع....توی پادگان میخونم، پادکست بی پلاس هم موقع برگشتن به خونه توی مسیر گوش میدم. پروژه x هم قسمت های اول و دومش را درست می کنم و میفرستم برای مشتری).آخر هر هفته حتما چک کنید چه کارهایی باعث خراب شدن برنامه ریزی شدن و چه نکاتی را تغییر بدید باعث بهتر شدن روندتون خواهد شد.تفریحات تون را حذف نکنید ولی مراقب باشید زمانشون از دستتون در نره.مثلا من سریال فرندز و بیگ بنگ و ... را که قبلا هم دیدم ولی اینبار محدود میکردم که روزی فقط یک قسمت از یکی از سریال ها را ببینم که هم جنبه فان داشت هم جنبه تقویت زبان :)به خودتون جایزه هم بدید :دی مثلا وقتی ی کار سنگین تموم میشه بعد از یکی دو هفته :)سعی کنید بین کتاب هایی که میخونید کتاب‌های انگیزشی/روانشناسی هم بخونید که هم شناخت بهتری از خودتون بدست بیارید هم به عنوان یک بسته انرژی‌زا گاهی نیازه. چون مغز آدم دوست داره کارها را ساده انجام بده با انرژی کمتر و این یعنی پیش به سوی تنبلی و عادت های بد. اما گاهی ی انرژی‌زا نیاز هست تا آدم اشتیاقش برگرده و بتونه ادامه بده.حتی اگر اهل کتاب نیستید گاهی یک کلیپ انگیزشی میتونه نقش همون بسته انرژی‌زا را داشته باشه، مثلا کلیپ زیر مربوط به کانال آپاراتی به نام irselfmade هست را ببینید: https://www.aparat.com/v/wXyB2 منابع این مدلی زیاد هستند توی اینترنت اما در مورد صبور بودن علاوه بر کلیپ بالا پست زیر را هم که قبل‌تر نوشته بودم را میتونید مطالعه کنید، در مورد اینکه گاهی ناامید و خسته میشیم از پیشرفت نکردن یا چیزی بلد نبودن! مخصوصا هرچی بیشتر یاد میگیریم حس بلد نبودن بیشتری بهمون دست میده: https://virgool.io/@hossein52hz/%D8%AA%D9%88%D9%87%D9%85-%D8%AA%D8%AE%D8%B5%D8%B5-%D9%88-%D8%A2%D8%BA%D8%A7%D8%B2-%D8%AA%D9%84%D8%A7%D8%B4-%D8%A8%D8%B1%D8%A7%DB%8C-%D9%85%D8%AA%D8%AE%D8%B5%D8%B5-%D8%B4%D8%AF%D9%86-%D8%A7%D8%AB%D8%B1-%D8%AF%D8%A7%D9%86%DB%8C%D9%86%DA%AF-%DA%A9%D8%B1%D9%88%DA%AF%D8%B1-aszhwi3wylfc باز هم میگم مشکل ما کمبود زمان نیست بلکه مشکل به مدیریت درست زمان و صبور بودن ما بر میگرده.معرفی کتاببرخی کتاب‌هایی که به نظرم خوندن شون ضرری به آدم نمیرسونه اون هم وسط این همه اتلاف وقت برای شبکه های اجتماعی و فیلم و سریال و دنبال کردن اخبار و .....که البته همه این کتاب ها داخل اپلیکیشن های کتابخوان که بالا معرفی کردم موجود هستن:کتاب اثر مرکب کتاب کار عمیقکتاب قدرت عادتکتاب مدیریت زمان برایان تریسینیازی نیست تمام گفته های کتاب را با جزئیات دقیق پیاده سازی کنید تو زندگی، همین که یک دید کلی بهتون بده و باعث آگاهی بیشتر شما بشه به نظرم کافیه.میدونم خیلی ها میگن این روش ها برای چند روز یا هفته جواب میده اما بعدش دیگه نمیشه ادامه داد و توی درازمدت الکی هستند یا توهمی بیش نیستند! اما به عنوان نمونه بخوام خروجی این مدل برنامه ریزی، تمرکز و کار کردن با استفاده از گوشی موبایل را بگم، قبل از سربازی چندماهی زمان داشتم و خب تونستم در کنار پروژه هام، کتاب هنر کدنویسی خوانا را ترجمه کنم که چند فصلش را داخل همین ویرگول منتشر کردم قبلا و نسخه کاملش هم در زیر در دسترس هست: http://book.tinybit.ir/ همونطور که گوشی و اپلیکیشن های نصب شده توسط ما میتونن زندگی را پر کنن از اتلاف وقت که منجر به اضطراب، استرس و سختی میشه، میتونن کمک کنند که برنامه ریزی و مدیریت بهتری داشته باشیم، مهم اینه چه اپلیکیشن هایی نصب می کنید :)این نوشته بخشی از تجربه من بود که واقعیتش میخواستم زودتر از این‌ها بنویسم ولی خب فرصت نشده بود تا اینکه دیدم #روایتگرباش بهونه خوبیه برای نوشتنش. راستی شما از چه اپلکیشنی استفاده می‌کنید؟ یا چه اپلیکیشن هایی را مفید میدونید؟ حسین مسعودی حسین مسعودی Thu, 17 Dec 2020 12:57:14 +0330 https://virgool.io/@hossein52hz/%D9%BE%DB%8C%D8%AF%D8%A7-%DA%A9%D8%B1%D8%AF%D9%86-api%D9%87%D8%A7%DB%8C-%D8%B9%D9%85%D9%88%D9%85%DB%8C-%D8%AF%D8%B1-%D8%A7%DB%8C%D9%86%D8%AA%D8%B1%D9%86%D8%AA-cwpntdmhf336 امروز توی سایت dev.to داشتم مقاله می‌خوندم که این مقاله را دیدم و به نظرم جالب و مفید بود، اینجا معرفیش می‌کنم شاید برای شما برنامه‌نویس‌ها و توسعه دهنده‌ها هم مفید باشه.اگر شما هم به دنبال API عمومی برای استفاده در پروژه های خودتون هستید و یا می‌خواهید چیزای باحال درست کنید، می‌تونید سایت public-apis.io را بررسی کنید و API مورد نظر خودتون را پیدا کنید.در حال حاضر این سایت لیستی از API های موجود توی اینترنت را همراه با یک سرچ پیشرفته فراهم کرده بنابراین شما به راحتی می‌تونید کلمه کلیدی خودتون در مورد APIای که به دنبالش هستید را سرچ کنید. تا الان لیستی حدود 700 مورد API توی 40 تا موضوع مختلف، در سایت اضافه شده.به عنوان مثال برخی از موضوعات را می‌تونید در زیر ببینید:Geocoding APIsDevelopment APIsData Access APIsCloud Storage APIsAnime APIsWeather APIsOpen DataMusic APIsبرای دیدن همه موضوعات اینجا کلیک کنید.ویژگی خیلی جالبی توی این سایت وجود دارد که شما می‌تونید APIهایی مورد علاقه تون را ذخیره کنید(داخل سایت امکان ثبت نام هست). کافیه روی Save کلیک کنید تا به لیست favorite هاتون اضافه بشه.برای دیدن لیست Favorite هاتون کافیه توی سایت لاگین کنید و به قسمت پروفایل تون برید. حسین مسعودی حسین مسعودی Fri, 10 Apr 2020 07:41:34 +0430 https://virgool.io/@hossein52hz/%D9%87%D9%86%D8%B1-%DA%A9%D8%AF%D9%86%D9%88%DB%8C%D8%B3%DB%8C-%D8%AE%D9%88%D8%A7%D9%86%D8%A7-%D8%B4%DA%A9%D8%B3%D8%AA%D9%86-%D8%B9%D8%A8%D8%A7%D8%B1%D8%AA%D9%87%D8%A7%DB%8C-%D8%BA%D9%88%D9%84-%D9%BE%DB%8C%DA%A9%D8%B1-jo16esmixxcc سلام به همه دوستان برنامه نویس :)واقعیتش من چند وقتی بود که داشتم کتاب "هنر کدنویسی خوانا" یا همان The Art of Readable Code را می‌خوندم و دیدم خیلی کتاب مفیدی هست و بد نیست که برنامه‌نویسان عزیز این کتاب را بخوانند، برای همین تصمیم گرفتم کتاب را ترجمه کنم و چند فصل از کتاب را هم توی ویرگول منتشر می‌کنم. امیدوارم مفید باشه و برنامه نویسان عزیزی مثل شما بعد از خوندن این کتاب کدهای تمیزتری بنویسید و کمی به شما در مسیر پیشرفت توی حوزه برنامه‌نویسی کمک کند.خب در این پست ویرگولی فصل هشتم کتاب هنر کدنویسی خوانا را با موضوع شکستن عبارت‌های غول پیکر به قسمت‌های کوچک، با هم دنبال می‌کنیم:فصل هشتم: شکستن عبارت‌های غول پیکر به قسمت‌های کوچک هنر کدنویسی خوانا:شکستن عبارت‌های غول پیکر به قسمت‌های کوچکتر ماهی مرکب غول پیکر، حیوانی شگفت انگیز و باهوش است، اما خلقت تقریبا کامل آن، یک نقص کشنده دارد چرا که مغز دونات شکل این ماهی به دور مری آن پیچیده شده است و اگر به یکباره غذای زیادی ببلعد، باعث آسیب رسیدن به مغزش می‌شود.ممکن است بپرسید این چه ربطی به کد دارد؟ پاسخ این است که کد نوشته شده در تکه‌های بسیار بزرگ می‌تواند اثر مشابه‌ای را داشته باشد. تحقیقات اخیر حاکی از آن است که اکثر ما در یک لحظه می‌توانیم، تنها به سه یا چهار چیز فکر کنیم. این به بیان ساده‌تر، یعنی هرچه عبارت‌های کد بزرگتر باشد، درک آن سخت‌تر خواهد بود.کلید طلایی: عبارت‌های غول پیکر خود را به قطعات قابل هضم‌تر تقسیم کنید.در این فصل روش‌های مختلفی را برای دستکاری و تجزیه کد به شما خواهیم آموخت تا بلعیدن آن‌ها ساده‌تر شود.متغیرها را شرح دهیدساده‌ترین روش برای تجزیه یک عبارت، معرفی متغیرهای اضافه‌ای است که یک زیرعبارت کوچکتر را تولید می‌کند. این متغیر اضافی گاه «متغیر توضیح دهنده» نامیده می‌شود، زیرا کمکی در جهت توضیح معنای زیرعبارت است. به عنوان مثال کد زیر را در نظر بگیرید:و حال این کد مشابه را که همراه با متغیرهای توضیح دهنده است را مشاهده نمایید:متغیرهای خلاصهحتی اگر یک عبارت نیازمند توضیح نباشد(البته به این دلیل که می‌توانید معنای آن را بفهمید)، باز هم گنجاندن آن عبارت در یک متغیر جدید مفید خواهد بود. البته اگر هدف از این کار صرفا جایگزینی آن کد با نامی کوچکتر است تا بتوان آن را راحت‌تر مدیریت یا به آن فکر کرد، این را یک متغیر خلاصه می‌نامیم.به عنوان مثال عبارت زیر را در این کد در نظر بگیرید:عبارت request.user.id == document.owner_id شاید بزرگ به نظر نرسد، اما دارای پنج متغیر است که باعث می‌شود زمان مورد نیاز برای فکر کردن به آن بیشتری شود.جمله «آیا کاربر مالک سند است؟»، مفهوم اصلی این کد است که با اضافه کردن یک متغیر خلاصه، این مفهوم می‌تواند به صورت روشن‌تری بیان شود:ممکن است این تغییر، چیزِ زیادی به نظر نرسد، اما دستور if (user_owns_document) برای فکر کردن، کمی ساده‌تر است. همچنین تعریف user_owns_document در ابتدای کد به خواننده می‌گوید که «این مفهومی است که ما در طی این تابع به آن خواهیم پرداخت».استفاده از قوانین دمورگاناگر درس مدار یا منطق را گذرانده باشید احتمالا قوانین دمورگان را به خاطر دارید. این قوانین دو راه برای نوشتن یک عبارت Boolean به شکل معادل آن هستند:1) not (a or b or c) ⇔ (not a) and (not b) and (not c)2) not (a and b and c) ⇔ (not a) or (not b) or (not c)گاه می‌توانید با استفاده از این قوانین خوانایی بیشتری در یک متغیر Boolean ایجاد کنید. به عنوان نمونه اگر کد شما به صورت زیر باشد:می توانید آن را به شکل زیر بنویسید:سوءاستفاده از منطق اتصال کوتاهدر اکثر زبان‌های برنامه‌نویسی، عملگرهای Boolean ارزیابی اتصال کوتاه را انجام می‌دهند. به عنوان مثال، دستور (if (a || b در صورتی که مقدار a برابر true باشد، مقدار b را بررسی نمی‌کند. هر چند این رفتار بسیار مفید است اما گاهی می‌تواند برای تحقق منطق پیچیده به شکل صحیح مورد استفاده قرار نگیرد.در اینجا مثالی از یک دستور تکی داریم:در زبان انگلیسی، آنچه که این کد می‌گوید این است: «برای این key مقدار bucket را بگیر، اگر مقدار bucket برابر null نبود، پس مطمئن شوید که اشغال نشده است». هر چند این فقط یک خط کد است ولی واقعا سبب توقف اکثر برنامه‌نویسان می‌شود تا کمی در مورد آن فکر کنند. اکنون آن را با کد زیر مقایسه کنید:این یکی حتی اگر دو خط کد باشد دقیقا همان کار را انجام داده و درک آن بسیار ساده‌تر است.ممکن است سوال کنید پس چرا در نسخه اول، این کد به صورت یک عبارت غول پیکر نوشته شده است؟ ممکن است بگوییم شاید در آن زمان، برنامه‌نویس احساس باهوشی می‌کرده و برایش لذت خاصی در تقسیم کردن منطق به یک قطعه کد مختصر وجود داشته است. البته این قابل درک است و مانند حل کردن یک پازل نقاشی است که همه ما دوست داریم در محل کار تفریح هم داشته باشیم ولی مشکل این است که این نوع کد برای کسانی که می‌خواهند آن را بخوانند، یک دست انداز ذهنی در برابر سرعت خواندن کد ایجاد می‌کند.کلید طلایی: مراقب قطعه کدهای هوشمندانه باشید. آن‌ها معمولا کسانی را که در آینده آن را می‌خوانند دچار سردرگمی می‌کنند.حال ببینیم که آیا این بدان معنی است که شما باید از کاربرد رفتار اتصال کوتاه خودداری کنید؟ خیر، موارد زیادی وجود دارد که می‌توان از آن به شکل شفاف استفاده کرد، همچون:شیوه جدیدتری نیز در اینجا وجود دارد که قابل ذکر است: در زبان‌ها‌یی مثل Python، JavaScript و Ruby عملگر or یکی از آرگومان‌ها را بر می‌گرداند(یعنی آن را به Boolean تبدیل نمی‌کند). بنابراین کد زیر:x = a || b || cمی تواند برای انتخاب اولین مقدار صحیح از a، b یا c استفاده شود.مثال: کشمکش با منطق پیچیدهفرض کنید که شما در حال پیاده سازی کلاس Range به این صورت هستید:تصویر زیر چند نمونه از محدوده‌ها را نشان می‌دهد:هنر کدنویسی خوانا: محدوده‌هاتوجه کنید که end یک کلمه غیرفراگیر است بنابراین A، B و C با یکدیگر همپوشانی نداشته اما D با همه همپوشانی دارد.یک تلاش برای پیاده سازی این وضعیت به این صورت است که قرار گیری هر نقطه انتهایی از یک محدوده در محدوده دیگر را بررسی می‌کند:ولو اینکه این کد تنها دو خط طولانی باشد، باز هم موارد بسیار زیادی در آن بررسی می‌شود. در تصویر زیر همه منطق موجود در این کد نشان داده شده است.هنر کدنویسی خوانا: محدوده‌هاموارد و شرایط بسیاری وجود دارد که باید درباره آن فکر شود، چرا که رخ دادن سهوی یک اشکال در این مورد راحت است. صحبت از این است که یک باگ وجود دارد. زیرا کد قبلی ادعای همپوشانی محدوده [0,2) با [2,4) را دارد در حالی که در واقعیت این چنین نیست.مشکل این است که باید در زمان مقایسه مقدارهای begin/end با استفاده از <= یا فقط > مراقب باشید. نمونه اصلاح شده آن را به این شکل است:اگرچه این مشکل برطرف شد ولی یک اشکال دیگر نیز وجود دارد! این کد مواردی که begin/end به صورت کامل دیگر موارد را پوشش می‌دهند، نادیده می‌گیرد. در اینجا نمونه اصلاح شده که این مورد را نیز مدیریت می‌کند، مشاهده می‌کنید:این کد بسیار پیچیده شده است. شما نمی‌توانید انتظار داشته باشید کسی بعد از خواندن این کد با اطمینان بگوید که صحیح است. پس باید چه کاری انجام دهیم؟ چگونه می‌توانیم این عبارت غول پیکر را تجزیه کنیم؟برای دریافت کامل کتاب با تخفیف ۴۰٪ می‌تونید از کد تخفیف virgool استفاده کنید. سایت تهیه کتابپیدا کردن یک رویکرد ظریف‌تراین نمونه یکی از مواقعی است که باید توقف کرده و رویکرد متفاوتی را در نظر بگیرید. آنچه به عنوان یک مشکل ساده شروع شد(یعنی بررسی اینکه دو محدوده با یکدیگر همپوشانی دارند یا نه) در نهایت به یک منطق پیچیده تعجب آور تبدیل گشت. این اغلب نشانه‌ای است برای این مطلب که: باید راهی آسان‌تر وجود داشته باشد.اما پیدا کردن یک راه حل ظریف‌تر نیازمند خلاقیت است. یک روش این است که ببینید آیا می‌توانید مسئله را در جهت معکوس حل کنید یا نه؟ بسته به موقعیتی که در آن قرار دارید، این کار می‌تواند با تکرار از طریق آرایه‌ها، به صورت معکوس و یا پر کردن برخی از ساختارداده‌ از انتها (به جای از ابتدا) انجام شود.در اینجا معکوس ()OverlapsWith به معنی «همپوشانی ندارد» است. تشخیص این موضوع که دو محدوده با هم همپوشانی نداشته باشند، مسئله‌ای ساده‌تر است، زیرا تنها دو امکان وجود دارد:1. محدوده دیگر قبل از شروع این محدوده به پایان می‌رسد.2. محدوده دیگر پس از پایان این محدوده شروع می‌شود.ما می‌توانیم این مطلب را به سادگی در کد پیاده‌سازی کنیم:هر خط از کد بسیار ساده بوده و تنها شامل یک مقایسه تکی است. این باعث می‌شود تا خواننده توان ذهنی خود را صرف این مسئله کند که آیا <= صحیح است یا خیر؟شکستن دستورات غول پیکرهرچند این فصل درباره شکستن عبارت‌های فردی است، اما همین روش‌ها، برای شکستن دستورات بزرگتر نیز کاربرد دارد. به عنوان مثال، موارد موجود در کد JavaScript زیر بیش از آن است که در یک نگاه بتوان همه آن‌ها را درک کرد:با اینکه عبارت‌های فردی در این کد چندان بزرگ نیستند، ولی از کنار هم قرار گرفتن آن‌ها، دستور غول پیکری شکل می‌گیرد که ممکن است سبب تعجب شما در یک لحظه شود. البته جای نگرانی نیست چرا که خوشبختانه به دلیل تشابه بسیاری از عبارت‌ها می‌توانیم آن‌ها را به عنوان یک متغیر خلاصه، در بالای تابع قرار دهیم(همچنین این کار نمونه‌ای از اصل DRY (یا خودت را تکرار نکن) است):با اینکه لزومی به ساختن var hi = "highlighted" نیست، اما از آنجا که شش نسخه از آن وجود دارد، مزایای قانع کننده‌ای دارد، از جمله اینکه:کمک می‌کند تا از اشتباهات تایپی جلوگیری شود(آیا در مثال اول متوجه اشتباه تایپی رشته highlighted در مورد پنجم شدید؟)· سبب کوتاه‌تر شدن عرض خط و در نتیجه ساده‌تر شدن بررسی کد در یک نگاه می‌شود.· اگر نام کلاس نیاز به تغییر داشته باشد، فقط یک مکان برای تغییر آن وجود دارد.یکی دیگر از روش‌های خلاقانه برای ساده کردن یک عبارتدر زیر مثال دیگری در زبان ++C که در هر عبارت آن اتفاقات زیادی می‌افتد را مشاهده می‌کنید:بار دیگر، چشمان شما با کدی دارای عباراتِ طولانی و مشابه هم (اما نه دقیقا یکسان) روبرو شده است. پس از ده ثانیه بررسی دقیق، ممکن است متوجه شوید که هر خط یک کار مشابه را در فیلدهای متفاوت انجام می‌دهد:در C می‌توانیم برای پیاده سازی چنین چیزی، از ماکروها استفاده کنیم:اکنون که همه قسمت‌های به هم پیچیده را از بین بردیم، می‌توانید بلافاصله با یک نگاه ماهیت اینکه چه اتفاقی می‌افتد را درک کنید. کاملا واضح است که هر خط از کد کار مشابه‌ای را انجام می‌دهد.البته توجه داشته باشید که ما همیشه از کاربرد ماکروها دفاع نمی‌کنیم. در واقع اصل اولیه اجتناب از آن‌ها است زیرا ماکروها می‌توانند سبب ایجاد سردرگمی در کد شده و معرف باگ‌های ظریفی باشند. اما گاهی اوقات همچون این مورد، به دلیل ساده بودن می‌توانند مزیت واضحی را برای خوانایی بهتر کد فراهم کنند.عبارت غول پیکر را به تکه‌هایی کوچکتر تقسیم کنیدفکر کردن در مورد عبارات غول پیکر سخت است. این فصل روش‌هایی را برای شکستن آن‌ها به قسمت‌های کوچک‌تر نشان داد، که خواننده بتواند آن‌ها را تکه به تکه هضم کند.یک روش ساده معرفی متغیرهای خلاصه است که مقدار بعضی از زیرعبارات بزرگ را در خود نگه می‌دارند. این کار سه مزیت دارد:عبارت غول پیکر را به تکه‌هایی کوچکتر تقسیم می‌کند.کد را با توصیف زیرعبارات در یک نام مختصر، مستند می‌کند.به خواننده کمک می‌کند تا مفاهیم اصلی کد را شناسایی کند.راه حل دیگر دستکاری منطق خود با استفاده از قوانین دمورگان است. این روش گاهی می‌تواند یک عبارت Boolean را به شیوه‌ای واضح‌تر بازنویسی کند، مثلا تغییر عبارت: if (!(a && !b)) به صورت:if (!a || b))ما مثالی که در آن منطق شرطی پیچیده، در دستورات کوچکی شبیه:"if (a < b)…" شکسته شد را نشان دادیم. در حقیقت همه کدهای بهبود داده شده در این فصل، دارای دستورات if بودند که بیشتر از دو مقدار داخل آن‌ها نبود. این‌ها مثال‌هایی برای تمرین بودند و ممکن است همیشه انجام چنین کاری امکان پذیر نباشد. گاهی این کار به بی اثر کردن مشکل یا در نظر گرفتن حالت معکوس هدف شما، نیاز دارد.سخن پایانی اینکه اگرچه این فصل درباره روش شکستن عبارتهای فردی بود، ولی این روش‌ها اغلب امکان استفاده برای بلوک‌های بزرگ را نیز دارند. بنابراین هر کجا با آن‌ها روبرو شدید برای شکستن منطق پیچیده به قسمت‌های کوچک‌تر، دریغ نکنید.برای دریافت کامل کتاب با تخفیف ۴۰٪ می‌تونید از کد تخفیف virgool استفاده کنید. سایت تهیه کتاب حسین مسعودی حسین مسعودی Sat, 14 Mar 2020 20:50:00 +0330 https://virgool.io/@hossein52hz/%D9%87%D9%86%D8%B1-%DA%A9%D8%AF%D9%86%D9%88%DB%8C%D8%B3%DB%8C-%D8%AE%D9%88%D8%A7%D9%86%D8%A7-%DA%86%D9%87-%DA%86%DB%8C%D8%B2%DB%8C-%D8%B1%D8%A7-%DA%A9%D8%A7%D9%85%D9%86%D8%AA-%DA%A9%D9%86%DB%8C%D9%85%D8%A8%D8%AE%D8%B4-%D8%AF%D9%88%D9%85-odwkj17lhu4r سلام به همه دوستان برنامه نویس :)واقعیتش من چند وقتی بود که داشتم کتاب "هنر کدنویسی خوانا" یا همان The Art of Readable Code را می‌خوندم و دیدم خیلی کتاب مفیدی هست و بد نیست که برنامه‌نویسان عزیز این کتاب را بخوانند، برای همین تصمیم گرفتم کتاب را ترجمه کنم و چند فصل از کتاب را هم توی ویرگول منتشر می‌کنم. امیدوارم مفید باشه و برنامه نویسان عزیزی مثل شما بعد از خوندن این کتاب کدهای تمیزتری بنویسید و کمی به شما در مسیر پیشرفت توی حوزه برنامه‌نویسی کمک کند.اگر بخش اول این فصل را نخوانده‌اید میتونید به نوشته هنر کدنویسی خوانا: چه چیزی را کامنت کنیم؟(بخش اول) مراجعه کنید.خب در این پست ویرگولی بخش دوم فصل پنجم کتاب هنر کدنویسی خوانا که با موضوع چه چیزی را کامنت کنیم؟ را با هم دنبال می‌کنیم:خودتان را جای خواننده بگذاریدیک تکنیک کلی که در این کتاب استفاده می‌کنیم این است که «تصور کنید که کد شما در نظر یک شخص خارجی چگونه به نظر می‌رسد»، کسی که به اندازه شما با این پروژه آشنا نیست. این تکنیک به ویژه برای تشخیص اینکه چه بخش‌هایی نیاز به کامنت گذاری دارند به شما کمک می‌کند.پیش بینی سوالات احتمالیهنر کدنویسی خوانا: پیش‌بینی سوالات احتمالیهنگامی که شخص دیگری کد شما را بخواند، بخش‌هایی وجود دارد که ممکن است در مورد بخش‌هایی از آن به این صورت فکر کند که «هااااااا؟ اینا اصلا در مورد چی هستند؟» کار شما این هست که این بخش‌ها را کامنت گذاری کنید. به عنوان مثال نگاهی به تعریف تابع ()Clear بیندازید:اکثر برنامه‌نویسان C++ در هنگام مواجه با این کد به این فکر خواهند کرد که: چرا در آن به جای تعویض با یک بردار خالی، فقط از ()data.clear استفاده نشده است؟ خب معلوم است که این تنها روش مجبور کردن یک بردار است، تا به درستی حافظه خود را به حافظه allocator رها سازی کند. این کار از جزئیات C++ است که به خوبی شناخته نشده است. بنابراین، باید اینگونه کامنت گذاری شود:اعلام کردن تله احتمالیهنگام مستند کردن یک تابع یا یک کلاس، سوال خوبی که می‌توانید از خود بپرسید این است که، چه چیز تعجب آوری در مورد این کد وجود دارد؟ چگونه ممکن است این کد سبب برداشت اشتباه خواننده شود؟ در واقع، شما دارید «به آینده فکر می‌کنید» تا مشکلاتی که احتمالا افراد در زمان استفاده از کد، به آن دچار می‌شوند را پیش بینی کنید.به عنوان مثال، فرض کنید تابعی نوشته‌اید که یک ایمیل را به کاربری معین ارسال می‌کند:هنر کدنویسی خوانا: اعلام کردن تله احتمالیپیاده سازی این تابع شامل اتصال به یک سرویس ایمیل خارجی است که ممکن است یک ثانیه کامل یا بیشتر زمان ببرد. شخصی که در حال نوشتن یک برنامه کاربردی وب است ممکن است متوجه این موضوع نشده و اشتباها این تابع را حین انجام درخواست HTTPفراخوانی کند که در صورت قطع سرویس ایمیل، انجام این کار سبب توقف برنامه کاربردی وب می‌گردد.برای جلوگیری از این اشتباه احتمالی، باید در مورد جزئیات پیاده سازی شده کامنت گذاری کنید:در اینجا مثال دیگری داریم، فرض کنید تابع ()FixBrokenHtml را دارید که تلاش می‌کند کدهای HTMLدارای اشکال را با افزودن تگ بسته شدن به انتهای آن‌ها، بازنویسی کند:این تابع در غیر از مواردی که حین اجرای آن تگ‌های بدون همتا و تو در توی بسیار زیادی وجود داشته باشد، خیلی عالی عمل می‌کند ولی برای ورودی‌های بهم ریخته و کثیف HTML اجرای این تابع می‌تواند چند دقیقه طول بکشد.به جای اینکه اجازه دهید کاربر خودش بعدها متوجه این موضوع شود، بهتر است که در یک کامنت و در همان ابتدای کار در مورد سرعت اجرای آن هشدار دهید:کامنت‌های روند کلیهنر کدنویسی خوانا: کامنت‌های روند کلییکی از سخت‌ترین موارد برای عضو جدید تیم، فهمیدن روند کلی برنامه است. اینکه تعامل کلاس‌ها چگونه است، جریان داده در کل سیستم به چه صورت بوده و نقاط ورودی کجاها هستند.طراح اصلی سیستم به دلیل درگیری زیاد با این موارد معمولا فراموش می‌کند که درباره آن‌ها کامنت گذاری کند.حال بیایید این آزمایش فکری را در نظر بگیرید: شخصی به تازگی به تیم شما اضافه شده است، او جلوی شما می‌نشیند تا شما او را با کدپایه آشنا کنید.شما در حال ارائه توضیحات در مورد کدپایه، ممکن است به فایل‌ها و کلاس‌های خاصی اشاره کنید و چیزی شبیه این جملات را بگویید:· این کد واسط بین منطق بیزینس ما و دیتابیس است. هیچ کد اپلیکیشنی نباید از این کد مستقیما استفاده کند.· این کلاس به نظر پیچیده می‌رسد، اما این در واقع یک Cache هوشمند است و در مورد بقیه سیستم چیزی نمی‌داند.پس از یک دقیقه مکالمه غیر جدی، عضو جدید تیم نسبت به زمانی که خودش به تنهایی می‌خواست سورس کد را بخواند، اطلاعات خوبی در مورد سیستم بدست می‌آورد.این دقیقا همان نوع اطلاعاتی است که باید به کامنت‌های سطح بالا اضافه شود.در اینجا یک مثال ساده از کامنت سطح-فایل داریم:از این فکر که حتما مجبور هستید یک سند رسمی و وسیع بنویسید نگران نشوید. انتخاب چند جمله خوب، بهتر از این است که هیچ چیزی نباشد.کامنت‌های خلاصهاین ایده خوبی است که حتی در عمق یک تابع، در مورد تصویر کلی‌تر آن، کامنت گذاری کنید. در اینجا مثالی از یک کامنت آورده شده است که کد سطح-پایین زیر آن را به صورت خلاصه بیان می‌کند:بدون این کامنت، خواندن هر خط از کد مقداری رمزآلود خواهد شد چرا که به نظر می‌رسد از طریق all_customers … در حال تکرار هستیم و این سوال پیش می‌آید که «این تکرار برای چیست؟».این کار زمانی مفید است که کامنت‌های خلاصه را در یک تابع بزرگتر داشته باشیم، جایی که تعدادی از تکه‌های بزرگ کد داخل آن‌ها وجود دارد.همچنین این کامنت‌ها می‌توانند به عنوان گزارش‌هایی خلاصه از اینکه توابع چه کاری انجام می‌دهند، عمل کنند، بنابراین قبل از اینکه خواننده وارد جزئیات تابع شود، می‌تواند به طور خلاصه کار انجام گرفته توسط تابع را بفهمد(البته اگر این تکه‌ها به آسانی قابل جدا شدن از یکدیگر هستند، بهتر است که آن‌ها را به شکل توابع جداگانه بنویسید. همان‌گونه که قبلا اشاره کردیم، کد خوب بهتر از کد بد با کامنت خوب است).دلایل کامنت گذاری: برای چه چیزی؟ چرا؟ یا چگونه؟ممکن است توصیه‌های سختگیرانه‌ای از این دست را شنیده باشید که: کامنت گذاری باید برای «چراباید انجام شود» باشد و نه برای «چه چیزی یا چگونه». این توصیه اگرچه قابل توجه است ولی ما فکر می‌کنیم که این دستورات خیلی ساده هستند و برای افراد مختلف معنای متفاوتی می‌دهند. توصیه ما این است که هر کاری که به خواننده برای درک ساده‌تر کد کمک می‌کند را انجام دهید. این امر ممکن است شامل کامنت گذاری در مورد چه چیزی، چگونه، یا چرا و یا حتی شامل هر سه این موارد باشد.افکار نهایی، گذر از بلوک نویسندهبسیاری از برنامه‌نویسان کامنت نویسی را دوست ندارند چرا که احساس می‌کنند باید کار زیادی برای نوشتن یک کامنت خوب، انجام شود. بهترین راه‌حل در مواجهه با این مانع احساسی این است که شروع به نوشتن کنید. بنابراین دفعه بعدی که در مورد نوشتن کامنت تردید داشتید، فقط جلو رفته و کامنتی در این مورد این که به چه چیزی فکر می‌کنید بنویسید، هرچند که کامل نباشد.به عنوان مثال فرض کنید شما روی یک تابع کار می‌کنید و با خود می‌اندیشید که: لعنت بهش، اگر تکراری در این لیست وجود داشته باشد، این چیزها دچار مشکل خواهد شد. فقط همین را به عنوان کامنت بنویسید:دیدید! خیلی سخت نبود. در واقع کامنت بدی هم نبود، هرچند کمی مبهم است ولی مطمئنا بهتر از هیچ است. برای حل این مشکل نیز می‌توانیم هر عبارت را مرور کرده و یک چیز خاص‌تر را جایگزین آن کنیم:· کلمه‌ای با معنی واقعی‌تر برای لعنت بهش! همچون این عبارت: مراقب باشید: این چیزی است که باید بیشتر مراقب آن باشید.· کلمه‌ای با معنی دقیق‌تر نیز برای this stuff همچون این عبارت: کدی که این ورودی را مدیریت می‌کند.· عبارتی رساتر برای اجرای آن دشوار خواهد بود همچون این عبارت: پیاده سازی آن سخت خواهد بود.احتمالا کامنت جدید به این صورت خواهد بود:توجه داشته باشید که ما نوشتن یک کامنت را به سه مرحله ساده تقسیم کردیم:1. هرچیزی که به عنوان کامنت در مغز شما است را بنویسید.2. کامنت را بخوانید، و هر چیزی را که نیازمند بهبود است، بهبود دهید.3. کل کامنت را بهبود دهید.هر چه کامنت بیشتری بنویسید، متوجه خواهید شد که کیفیت کامنت‌ها در هر مرحله بهتر و بهتر می‌شوند و در نهایت ممکن است کامنت شما اصلا نیازی به اصلاح نداشته باشد. همچنین با کامنت گذاری در اوایل و اغلب اوقات، از وضعیت ناخوشایندِ نیاز به نوشتن یک دسته از کامنت‌ها در پایان، خودداری خواهید کرد.برای دریافت کامل کتاب با تخفیف ۴۰٪ می‌تونید از کد تخفیف virgool استفاده کنید. سایت تهیه کتاب حسین مسعودی حسین مسعودی Fri, 13 Mar 2020 17:18:10 +0330 https://virgool.io/@hossein52hz/%D9%87%D9%86%D8%B1-%DA%A9%D8%AF%D9%86%D9%88%DB%8C%D8%B3%DB%8C-%D8%AE%D9%88%D8%A7%D9%86%D8%A7-%DA%86%D9%87-%DA%86%DB%8C%D8%B2%DB%8C-%D8%B1%D8%A7-%DA%A9%D8%A7%D9%85%D9%86%D8%AA-%DA%A9%D9%86%DB%8C%D9%85%D8%A8%D8%AE%D8%B4-%D8%A7%D9%88%D9%84-bnhrq76tcsve سلام به همه دوستان برنامه نویس :)واقعیتش من چند وقتی بود که داشتم کتاب "هنر کدنویسی خوانا" یا همان The Art of Readable Code را می‌خوندم و دیدم خیلی کتاب مفیدی هست و بد نیست که برنامه‌نویسان عزیز این کتاب را بخوانند، برای همین تصمیم گرفتم کتاب را ترجمه کنم و چند فصل از کتاب را هم توی ویرگول منتشر می‌کنم. امیدوارم مفید باشه و برنامه نویسان عزیزی مثل شما بعد از خوندن این کتاب کدهای تمیزتری بنویسید و کمی به شما در مسیر پیشرفت توی حوزه برنامه‌نویسی کمک کند. خب در این پست ویرگولی فصل پنجم کتاب هنر کدنویسی خوانا که با موضوع چه چیزی را کامنت کنیم؟ است را با هم دنبال می‌کنیم:فصل پنجم: چه چیزی را کامنت کنیم؟هنرکدنویسی خوانا: چه چیزی را کامنت کنیم؟هدف این فصل کمک به برای فهمیدن این نکته است که «چه چیزی را باید کامنت کنید». احتمالا می‌گویید هدف از نوشتن کامنت، توضیح این است که کد چه کاری انجام می‌دهد، اما این تنها بخش کوچکی از فواید کامنت نوشتن است.کلید طلایی: هدف از نوشتن کامنت کمک به خواننده است تا به همان اندازه که نویسنده کد آن را درک کرده، خواننده نیز کد را بفهمد.هنگامی که در حال نوشتن کد هستید، اطلاعات با ارزش زیادی در مغزتان دارید، ولی زمانی که دیگران کد شما را می‌خوانند، این اطلاعات با ارزش وجود ندارند. تنها چیزی که آن‌ها دارند، کدی است که جلوی آن‌ها قرار دارد.در این فصل مثال‌های زیادی را در این مورد که چه زمانی این اطلاعات داخل مغزتان را به شکل کامنت بنویسید، به شما نشان خواهیم داد. البته به مواردی که جذابیت کمتری دارند، نمی‌پردازیم، در عوض بر روی جنبه‌های جالب‌تر و «مورد توجه قرار نگرفته» از کامنت گذاری متمرکز می‌شویم.در این فصل به سه بخش مهم خواهیم پرداخت:دانستن اینکه چه چیزی را کامنت نکنیم.ثبت افکارتان همانند کدنویسی‌تان.قرار دادن خودتان به جای خواننده، تا تصور کنید که چه چیزی را باید بداند.چه چیزی را نباید کامنت کنیمهنر کدنویسی خوانا: چه چیزی را نباید کامنت کنیم!از آنجا که خواندن یک کامنت زمان زیادتری از خواندن کد برده و فضایی را در بالای صفحه اشغال می‌کند، بهتر است چیزی که مد نظر دارید ارزش کامنت نوشتن را داشته باشد. حال این سوال مطرح می شود که چگونه می‌توان مرز بین یک کامنت بی ارزش و یک کامنت خوب را فهمید؟تمام کامنت‌های کد زیر بی ارزش هستند:زیرا هیچ اطلاعات جدیدی را ارائه نداده و هیچ کمکی برای درک بهتر کد به خواننده نمی‌کنند.کلید طلایی: در مورد حقایقی که خودشان می‌توانند سریعا با خواندن کد به دست آیند، کامنت ننویسید.البته استفاده از این کلید طلایی نسبی است، به عنوان مثال کامنت زیر را که برای کد پایتون نوشته شده است در نظر بگیرید:از نظر فنی، این کامنت هیچ اطلاعات جدیدی را ارائه نداده و اگر خودتان به کد نگاه کنید، در نهایت متوجه خواهید شد که چه کاری انجام می‌دهد. اما برای اکثر برنامه‌نویسان، خواندن کد کامنت گذاری شده خیلی سریعتر از فهمیدن کد بدون کامنت است.فقط برای اینکه کدتان کامنت داشته باشد! کامنت گذاری نکنیدهنر کدنویسی خوانا:فقط برای اینکه کدتان کامنت داشته باشد! کامنت گذاری نکنید!بعضی از اساتید، دانشجویان را ملزم به کامنت گذاری برای هر تابع در تکالیف کدنویسی خود می‌کنند. در نتیجه بعضی از برنامه‌نویس‌ها در مورد رها کردن یک تابع بدون داشتن کامنت احساس گناه کرده و در پایان، اسم توابع و آرگومان‌های آن را در یک جمله به صورت کامنت بازنویسی می‌کنند:همان‌گونه که مشاهده می‌کنید کامنت‌های این کد در دسته کامنت‌های بی ارزش قرار می‌گیرد چرا که تعریف تابع و کامنت نوشته شده تقریبا یکسان هستند. برای بهبود این کد، این کامنت باید حذف شود.اگر می‌خواهید کامنتی در اینجا داشته باشید، می‌توانید در مورد جزئیات مهم‌تر نیز توضیح دهید:برای نام‌های بد کامنت ننویسید، در عوض، نام‌های بهتری انتخاب کنیدلازم نیست یک کامنت، بد بودن یک نام را جبران کند. برای مثال، در اینجا یک کامنت بی فایده برای تابعی به نام ()CleanReply نوشته شده است:بخش اعظم این کامنت در حال توضیح این مطلب است که معنی clean چیست. کافی است به جای آن عبارت «enforce limits» به نام تابع اضافه شود:نام جدید این تابع اطلاعات مستند زیادی در خودش دارد. به یاد داشته باشید که یک نام خوب، بهتر از یک کامنت خوب است زیرا نام تابع در هرجایی که تابع استفاده شده باشد، دیده می‌شود.در ادامه مثال دیگری از استفاده کامنت به دلیل انتخاب یک نام ضعیف برای یک تابع را مشاهده می‌کنید:به نظر می‌رسد نام ()DeleteRegistry شبیه یک تابع خطرناک است(این تابع حافظه registery را delete می‌کند؟!). کامنت نوشته شده به معنی «در واقع این رجیستری را تغییر نمی‌دهد» است و تلاش می‌کند که از گنگ بودن نام تابع، رفع ابهام کند.به جای آن می‌توانیم از یک نام خود-مستندساز بهتر به صورت زیر استفاده کنیم:به طول کلی، شما نمی‌خواهید کامنت‌های crutchداشته باشید[1]. کامنت‌های crutch، کامنت‌هایی هستند که سعی می‌کنند ناخوانا بودن کد شما را جبران کنند. کدنویس‌ها اغلب این وضعیت را به شکل یک قانون، این گونه بیان می‌کنند که: «کد خوب بهتر از کد بد + کامنت خوب» است.ثبت افکار خودحال که فهمیدید چه چیزی را کامنت نکنید، بیایید در این مورد که چه چیزی را باید کامنت کنیم، بحث کنیم.اکثر کامنت‌های خوب می‌توانند به سادگی از جمله «ثبت افکار خود» به دست آیند، که شامل مهمترین افکار شما، هنگام نوشتن کد می‌باشند.افزودن «توضیحات کارگردان»فیلم‌ها اغلب بخشی با عنوان «توضیحات کارگردان» دارند که در آن فیلم‌ساز بینش خود را ارائه داده و داستان‌هایی را برای کمک به فهمیدن اینکه این فیلم چطور ساخته شده است، بیان می‌کند. به طور مشابه، شما نیز باید کامنت‌ها را برای ثبت دیدگاه‌های با ارزش درباره کد اضافه کنید.به عنوان مثال این کامنت:چیزهایی را به خواننده یاد داده و از هرگونه اتلاف وقت آنان جلوگیری می‌کند.به عنوان مثال دیگر کامنت زیر را در نظر بگیرید:بدون نوشتن این کامنت، خواننده ممکن است فکر کند که یک اشکال وجود داشته و بخشی از زمان خود را هنگام تلاش برای تست مواردی که باعث شکست کد می‌شود، تلف کند و یا حتی سعی کند باگ آن را رفع نماید.همچنین یک کامنت می‌تواند دلیل عالی نبودن شکل ظاهری کد را شرح دهد:این کامنت می‌گوید که کد ما کثیف است اما همچنان نفر بعدی را برای ترمیم آن تشویق می‌کند(با ارائه مشخصاتی در مورد چگونگی بهبود آن).با نبود هیچ کامنتی، خیلی از خواننده‌ها با دیدن کدهای کثیف دچار ترس شده و از دست زدن به آن‌ها خودداری می‌کنند.نقص‌های موجود در کد خود را کامنت کنیدکد به طور مداوم در حال تغییر و تحول است و در طی این مسیر حتما نقص‌هایی خواهد داشت. از مستند کردن این نقص‌ها خجالت نکشید. مثلا، زمانی که کد نیازمند به بهبودی است می‌توانید از عبارت زیر استفاده کنید:یا هنگامی که کد کامل نشده است:برخی از نشانه‌هایی که بین برنامه‌نویسان رایج و محبوب شده‌اند را می‌توانید مشاهده کنید:هنر کدنویسی خوانا: نشانه‌ها در بهبود کدنویسیممکن است تیم شما قراردادی برای زمان یا شرط استفاده از این نشانه‌ها داشته باشد. به عنوان مثال TODO ممکن است برای نشان دادن توقف اشکالاتِ رزرو شده باشد. اگر چنین است، پس برای نقص‌های جزئی‌تر می‌توانید بجای TODO از چیزی شبیه todo (با حروف کوچک) و یا maybe-later استفاده کنید.نکته مهم این است که شما باید همیشه در مورد افکار خود، و نیز در این مورد که کد باید در آینده چه تغییری پیدا کند، راحت کامنت بنویسید. کامنت‌هایی شبیه این عبارات، به خوانندگان بینش بهتری در مورد کیفیت و وضعیت کد داده و حتی ممکن است در مورد چگونگی بهبود کد نیز ایده‌هایی به آن‌ها بدهد.در مورد ثابت‌ها کامنت بنویسیدهنگام تعریف یک ثابت، غالبا این سوال وجود دارد که چرا این متغیر ثابت، مقدار خاصی دارد و مقدار خاص آن چیست؟ به عنوان مثال ممکن است چنین ثابتی را در کد خود ببینید:به نظر نمی‌رسد که این خط، نیازمند کامنت باشد، اما به احتمال زیاد برنامه‌نویسی که آن را انتخاب کرده است اطلاعات بیشتری در مورد آن می‌داند:با این کامنت، شخصی که کد را می‌خواند یک راهنما در مورد نحوه تنظیم این متغیر ثابت دارد(به عنوان مثال، تنظیم آن به مقدار ۱ یا ۵۰ احتمالا به ترتیب خیلی کم یا بیش از حد زیاد است).گاهی اوقات مقدار دقیق یک ثابت به هیچ وجه مهم نیست که در این موارد، وجود یک کامنت، مفید به نظر می‌رسد:گاهی نیز این ثابت دارای مقداری است که بسیار دقیق تنظیم شده است و احتمالا نباید خیلی تغییر داده شود:در همه این مثال‌ها ممکن است شما به اضافه کردن کامنت فکر نکرده باشید، اما این کار، کاملا مفید است. برخی از ثابت‌ها هستند که نیاز به کامنت ندارند، زیرا نام آن‌ها به اندازه کافی واضح است(مثلا: SECONDS_PER_DAY). اما تجربه به ما ثابت کرده است که بیشتر ثابت‌ها را می‌توان با افزودن کامنت بهبود داد. مسئله این است که شما در زمان تصمیم گیری در مورد مقداردهی این ثابت به چه چیزی فکر می‌کرده‌اید).[1] یک اصطلاح به معنی عصای کمکی زیر بغل داشتن است. در اینجا منظور این است که کامنت به عنوان عصای کمکی برای فهماندن کد به خواننده استفاده شود.نکته پایانی اینکه: پیشاپیش اگر پیشنهاد، انتقاد و تجربه‌ای دارید، خوشحال و ممنون میشم که توی بخش نظرات مطرح کنید.برای دریافت کامل کتاب با تخفیف ۴۰٪ می‌تونید از کد تخفیف virgool استفاده کنید. سایت تهیه کتاب حسین مسعودی حسین مسعودی Fri, 13 Mar 2020 17:16:19 +0330 https://virgool.io/@hossein52hz/%D9%87%D9%86%D8%B1-%DA%A9%D8%AF%D9%86%D9%88%DB%8C%D8%B3%DB%8C-%D8%AE%D9%88%D8%A7%D9%86%D8%A7-%DA%A9%D8%AF-%D8%A8%D8%A7%DB%8C%D8%AF-%D8%A8%D9%87-%D8%A2%D8%B3%D8%A7%D9%86%DB%8C-%D9%82%D8%A7%D8%A8%D9%84-%D8%AF%D8%B1%DA%A9-%D8%A8%D8%A7%D8%B4%D8%AF-oc7kgbb7emh0 سلام به همه دوستان برنامه نویس :)واقعیتش من چند وقتی بود که داشتم کتاب "هنر کدنویسی خوانا" یا همان The Art of Readable Code را می‌خوندم و دیدم خیلی کتاب مفیدی هست و بد نیست که برنامه‌نویسان عزیز این کتاب را بخوانند، برای همین تصمیم گرفتم کتاب را ترجمه کنم و چند فصل از کتاب را هم توی ویرگول منتشر می‌کنم. امیدوارم مفید باشه و برنامه نویسان عزیزی مثل شما بعد از خوندن این کتاب کدهای تمیزتری بنویسید و کمی به شما در مسیر پیشرفت توی حوزه برنامه‌نویسی کمک کند.خب در این پست ویرگولی فصل اول کتاب هنر کدنویسی خوانا را با موضوع کد باید به آسانی قابل درک باشد، با هم دنبال می‌کنیم:فصل اول: کد باید به آسانی قابل درک باشدهنر کدنویسی خوانا: کد باید به آسانی قابل درک باشدحدود پنج سال قبل، ما هزاران مثال از کدهای بد را جمع آوری کردیم( که البته اکثرشان متعلق به خود ما بود)، سپس آن‌ها را از این جهت که چه عاملی سبب بد شدن آن‌ها شده بود و نیز قوانین و تکنیک‌هایی که برای بهتر شدن آن‌ها استفاده کرده بودیم را مورد بررسی قرار دادیم. آنچه متوجه شدیم این بود که همه اصول ناشی از یک مورد واحد است.کلید طلایی: کد باید به آسانی درک شود.ما معتقدیم این کلید طلایی، مهمترین اصل راهنمایی است که می‌توانید هنگام تصمیم گیری در مورد نوشتن کد خود استفاده کنید.در طول این کتاب، نشان خواهیم داد که چگونه می‌توانید این اصل را در جنبه‌های مختلف کدنویسی‌های روزانه خود بکار ببرید. اما قبل از شروع، اجازه دهید در این مورد که چرا این اصل اینقدر مهم است، توضیح دهیم.چه چیزی باعث بهتر شدن کد می‌شود؟اکثر برنامه‌نویسان(از جمله خود من) تصمیمات برنامه‌نویسی را بر اساس احساسات و دریافت ناگهانی می‌گیرند.همه ما می‌دانیم که کدی شبیه این:بهتر از کدی شبیه به این یکی است:حتی اگر فکر کنید که هر دو مثال دقیقاً شبیه هم عمل می‌کنند، اما در بسیاری از مواقع این انتخاب سخت است، برای مثال کد زیر را ببینید:و با کد زیر مقایسه کنید:نسخه اول فشرده‌تر است، اما نسخه دوم کمتر ترسناک است. به نظر شما کدام معیار اهمیت بیشتری دارد؟ فشردگی یا ترسناک نبودن؟ به طور کلی چگونه تصمیم می‌گیرید که با چه معیاری چیزی را کدنویسی کنید؟قضیه بنیادی خواناییبعد از مطالعه کدهای زیادی شبیه کدهای بالا، ما به این نتیجه رسیدیم که یک معیار برای خوانایی وجود دارد که مهم‌تر از بقیه موارد است. این معیار خیلی مهم است به همین دلیل آن را قضیه بنیادی خوانایی نام گذاری می‌کنیم.کلید طلایی: کد باید به گونه‌ای نوشته شود که زمان فهمیدن آن توسط شخص دیگر، کمترین میزان ممکن باشد.منظور ما از این جمله چیست؟ در واقع اگر شما از یک همکار معمولی خود بخواهید که کدتان را بخواند و در همان زمان، مقدار زمانی که او کد شما را خوانده و درک می‌کند را اندازه بگیرید، این «زمانِ تا فهمیدن» معیاری تئوری خواهد بود که شما برای حداقل بودن زمان درک کدتان نیاز دارید.زمانی که می‌گوییم «درک کردن»، این کلمه بار معنایی زیادی دارد. برای اینکه کسی کد شما را به طور کامل درک کند، باید بتواند در آن تغییرات ایجاد کرده، اشکالات آن را پیدا کند و نحوه تعامل این کد با بقیه برنامه شما را بفهمد.ممکن است به این فکر کنید که چه کسی اهمیت می‌دهد که شخص دیگری بتواند کد را درک کند یا نه؟ من تنها کسی هستم که از این کد استفاده می‌کنم! ولی بدانید که حتی اگر در یک پروژه تک نفری هستید، دنبال کردن این هدف ارزشش را دارد، چرا که ممکن است شش ماه بعد، یعنی زمانی که کدتان برای شما ناآشنا شده، آن شخص دیگر، خود شما باشید، همچنین ممکن است شخص دیگری به پروژه شما بپیوندد یا کد بی مصرف شما در پروژه دیگری مجدداً استفاده شود، پس هم اکنون ارزش دارد که کد خود را قابل درک بنویسید.آیا همیشه کوتاه‌تر بودن بهتر است؟به طور کلی، هرچه کد کمتری برای حل یک مسئله بنویسید، بهتر است.(به فصل ۱۳ مراجعه کنید). بی‌شک درک یک کلاس ۲۰۰۰ خطی نسبت به یک کلاس ۵۰۰۰خطی زمان کمتری از شما می‌گیرد.اما خطوط کمتر همیشه هم بهتر نیست! در مواقع زیادی شما با یک عبارت تک خطی، شبیه این عبارت مواجه می‌شوید:این حالت، نسبت به حالتی که عبارت دو خطی است، زمان بیشتری برای درک کد از شما می‌گیرد:به طور مشابه، یک کامنت می‌تواند سبب درک سریعتر کد شود، حتی اگر کد بیشتری را به فایل اضافه کند:بنابراین هر چند داشتن خطوط کد کمتر هدف خوبی است، ولی به حداقل رساندن زمان درک کردن[1] کد، هدفی بهتر است.آیا معیار «زمان درک کردن کد» با دیگر اهداف تداخل دارد؟احتمالا به این فکر می‌کنید که، پس سایر محدودیت‌ها را چه کنیم؟ مثلاً کارآمدی[2]بهتر کد، یا معماری بهتر یا ساده بودن کد برای تست، یا دیگر موارد؟ آیا گاهی اوقات، این موارد با کاری که می‌خواهید برای راحت‌تر درک شدن کد انجام دهید، تداخل ندارند؟ما متوجه شدیم هیچ تداخلی با اهداف دیگر وجود ندارد. حتی در حوزه کدهای بسیار بهینه، هنوز می‌شود با روش‌هایی آن‌ها را بسیار خواناتر نمود. نوشتن کد به شکلی که ساده‌تر درک شود، در موارد زیادی کدهایی را نتیجه می‌دهد که معماری خوبی داشته و تست آن‌ها نیز ساده‌تر است.در ادامه کتاب در مورد چگونگی «ساده خوانده شدن کد» در شرایط مختلف بحث خواهد شد. اما هر زمان که دچار تردید شدید، به یاد داشته باشید که «قضیه اساسیِ خوانایی»، هر قانون یا اصل دیگری در این کتاب را به زیر کشده و همیشه حرف اول را می‌زند.همچنین برخی از برنامه‌نویس‌ها برای تصحیح کدهایی که به خوبی بازسازی نشده‌اند نیاز به اجبار دارند. همیشه این سوال مهم است که برگردیم و بپرسیم، آیا این کد برای درک شدن آسان است؟ اگر بله، احتمالاً خوب است، پس بررسی کدهای دیگر را ادامه می‌دهیم.قسمت سخت کاربله، شما به تمرین‌های زیادی نیاز دارید. این تمرین که باید به طور دائم شخصی خیالی را که بتواند به راحتی کد شما را درک کند، در نظر بگیرید. انجام این کار مستلزم روشن کردن بخشی از مغز است که ممکن است قبلاً هنگام کدنویسی روشن نشده باشد.اگر این هدف را در نظر داشته باشید(همانگونه که هدف ما است)، یقین داریم که به یک کدنویس بهتر تبدیل خواهید شده و کمتر باگ خواهید داشت. همچنین بیشتر به کار خود افتخار نموده و کدی تولید خواهید کرد که هر شخص دیگری مشتاقانه از آن استفاده خواهد نمود. پس بیاید شروع کنیم!برای دریافت کامل کتاب با تخفیف ۴۰٪ می‌تونید از کد تخفیف virgool استفاده کنید. سایت تهیه کتاب حسین مسعودی حسین مسعودی Fri, 13 Mar 2020 16:46:26 +0330 https://virgool.io/@hossein52hz/%D8%AA%D9%88%D9%87%D9%85-%D8%AA%D8%AE%D8%B5%D8%B5-%D9%88-%D8%A2%D8%BA%D8%A7%D8%B2-%D8%AA%D9%84%D8%A7%D8%B4-%D8%A8%D8%B1%D8%A7%DB%8C-%D9%85%D8%AA%D8%AE%D8%B5%D8%B5-%D8%B4%D8%AF%D9%86-%D8%A7%D8%AB%D8%B1-%D8%AF%D8%A7%D9%86%DB%8C%D9%86%DA%AF-%DA%A9%D8%B1%D9%88%DA%AF%D8%B1-aszhwi3wylfc اثر دانینگ کروگرطبق معمول و قبل از شروع بحث سری به ویکی‌پدیا می‌زنیم تا تعریفی که از اثر دانینگ-کروگر ارائه شده را مطالعه کنیم. بخش مد نظر بحث ما به نقل از ویکی‌پدیا:اثر دانینگ-کروگر (به انگلیسی: Dunning–Kruger effect) نوعی سوگیری شناختی در افراد غیرحرفه‌ای است که از توهم برتری رنج می‌برند و به اشتباه، توانایی‌شان را بسیار بیش از اندازهٔ واقعی ارزیابی می‌کنند. این جانبداری به ناتوانی فراشناختی افراد غیرحرفه‌ای در شناسایی ناتوانیشان نسبت داده می‌شود. برعکس، افراد خیلی حرفه‌ای، گرایش بیشتری به دست‌کم‌گرفتن شایستگی خود داشته و به نادرست تصور می‌کنند که کاری که برای‌شان آسان است، برای دیگران نیز آسان است. اما داستان اصلی چیه؟خیلی از آدم‌های اطرافم را می‌بینم که با شروع یادگیری یک تخصص مثلا برنامه نویسی یا هر رشته دیگه‌ای اعتماد به نفس خیلی خیلی زیادی دارن و فکر میکنن که خیلی خفن شدن :) و در واقع تخمین واقعی از توانایی‌شون نمی‌تونن داشته باشند و این توهم‌شون ادامه پیدا می‌کنه تا موقعی که مثلا توی مصاحبه شغلی یک شرکت ثبت‌نام می‌کنند یا وارد جمع متخصص‌ها میشن یا در توییتر بحث‌های فنی و سوال و جواب‌های دوستان حرفه‌ای را می‌خونن و با سوالات فنی مواجه می‌شن. خیلی از اصطلاحات و جملات فیلد تخصصی که درخواست استخدام دادن اصلا تا حالا به گوششون هم نخورده چه برسه به اینکه در موردش تجربه عملی داشته باشند و بخوان بحث فنی کنند.(مثال خیلی ملموسش که دیدم: طرف دانشجوی رشته کامپیوتر بدون دانش عملی خاصی اعلام امادگی کرده بود که می‌تونه سایت/سرویس شبیه اینستاگرام برای مشتری پیاده کنه با هزینه ۵۰۰ هزار تومن :دی)نقطه حماقت و ناامیدیاینجا نقطه شروعی هست که شما متوجه میشید چیز خاصی بلد نیستید و یک نوع حس حماقت دارید. و این حس حماقت ادامه پیدا می‌کنه تا اینکه به مرحله ناامیدی نزدیک می‌شید. توی این مرحله یا بیخیال اون فیلد می‌شید و به فکر تغییر شغل می‌افتید یا اینکه تصمیم می‌گیرید شروع کنید بصورت اصولی مفاهیم پایه را یاد بگیرید، مثال‌های مختلفی حل کنید، پروژه عملی پیاده سازی کنید(به عنوان نمونه کار) و تمرین تمرین تمرین کنید.پیش به سوی تخصصتوی این مرحله که مرحله دانش هست شما آروم آروم شروع می‌کنید به کسب دانش توی فیلد مورد علاقه‌تون و بعد از مدتی این حس حماقت اثرش کمتر و کمتر میشه و از طرف دیگه حس توانایی مثبت و تخصص‌تون خودشا نشون میده و آشکار میشه. و با ادامه پیدا کردن این مسیر شما به یک متخصص در فیلد مورد علاقه‌تون تبدیل می‌شید.اگر کتاب اثر مرکب را نخوندید پیشنهاد می‌کنم در اولین فرصت مطالعه کنید. از مرحله ناامیدی تا آشکار شدن توانایی و تخصص برخلاف انتظارات و توقعات ما که دوست داریم توی یکی دوماه همه چی را سریع یاد بگیریم، کمی زمانبر هست و با خوندن این کتاب با واقعیت آشنا می‌شید و تصمیمات واقع‌گرایانه تری می‌گیرید و انتظارات و توهمات یک شبه متخصص شدن را کنار میزارید.مسیر پیشرفت و مقایسه خودتون با خودتوناما این امکان وجود داره که حتی بعد از بدست آوردن تخصص شما با مباحث جدیدتری آشنا بشید و هر چقدر جلوتر برید احساس کنید که چیزی بلد نیستید و این مسیر بصورت یک حلقه for ادامه پیدا کنه. پیشنهاد می‌کنم توی نقطه ناامیدی اول وضعیت خودتون را توی دفترچه‌ای، تابلویی یا هرجایی که راحت‌تر هستید، بنویسید . بعد از تمرین و بدست آوردن دانش و در مسیر تبدیل شدن به یک متخصص اگر این حس حماقت مجدد سراغ‌تون اومد، برید اون دفترچه را بردارید و دانش و تغییراتی که الان دارید را یادداشت کنید و با مرحله اولیه ناامیدی مقایسه کنید. مزیت این کار این هست که شما خودتون را با گذشته خودتون مقایسه می‌کنید و متوجه میشید که چقدر نسبت به قبل پیشرفت داشتید و مهمترین نکته‌ش اینه که خودتون را با دیگران مقایسه نکردید. این باعث میشه حس خوبی داشته باشید. و برای ادامه مسیر دانش جدید کسب کنید.ممکنه برای شما هم سوال پیش بیاد که این مسیر دانش چقدر ممکنه طول بکشه؟ باید بگم که این مسیر حداقل برای دنیای IT که به سرعت در حال تغییر و بروزرسانی و ارائه شیوه‌های جدیده تا جایی که شما استاپ نزنید ادامه داره و انتهایی نداره. ولی خب وقتی شما به دانش قابل قبولی رسیدید و پروژه‌های مختلف انجام دادید یا توی شرکت‌های خوبی استخدام شدید این مسیر بهبود پیدا می‌کنه. می‌تونید از دوستاتون چیزای جدید یاد بگیرید و مسیر را ادامه بدید. فقط حواستون باشه توی تله استخدام شدم دیگه نیازی به پیشرفت ندارم، نیافتید. چون ممکنه فردا روزی شرکت به هر دلیلی دیگه وجود نداشته باشه یا شما تمایل نداشته باشید باهاشون ادامه بدید، پس همیشه به فکر بروز نگه داشتن خودتون باشید:)اگر شما هم تجربه‌ یا پیشنهادی در بهبود این مطلب دارید خوشحال می‌شم در بخش نظرات بیان کنید تا دیگر دوستان هم از تجربیات شما استفاده کنند. حسین مسعودی حسین مسعودی Sat, 21 Sep 2019 11:05:20 +0430 https://virgool.io/@hossein52hz/%D9%85%D9%88%D8%AC%D9%88%D8%AF%DB%8C-%D8%B9%D8%AC%DB%8C%D8%A8-%D8%A8%D9%87-%D9%86%D8%A7%D9%85-bloom-filter-%D8%AF%D8%B1-%D8%A8%D8%B1%D9%86%D8%A7%D9%85%D9%87-%D9%86%D9%88%DB%8C%D8%B3%DB%8C-iajb0fn0ata1 بلوم فیلتر و کاربرد آن در برنامه نویسی خُب این بلوم فیلتر چیه و به چه دردی میخوره را من هم نمی‌دونستم تا اینکه توی مقاله‌ای برای کاهش مصرف حافظه و کاهش افزونگی داده‌های تبادل شده بین نودهای شبکه‌های تحمیل پذیر تاخیر یا DTN بهش برخوردم که البته الان DTN موضوع مورد بحثم نیست و بعدا در یک نوشته جدا بهش می‌پردازم.بیاید بریم سراغ ویکی‌پدیا، اگر سری به ویکی پدیا بزنید یک تعریف جالب از ساختار داده‌های احتمالاتی می‌بینید که در بخشی توضیح داده که از خطای مثبت کاذب و منفی استفاده می کنه. اما داستان وقتی جالب تر میشه که به بخش زیر در ادامه توضیحات بلوم فیلتر بر می‌خوریم و با این تعریف روبرو می‌شویم:فرض کنید می‌خواهیم وجود یک عنصری را در مجموعه جستجو کنیم، اگر ساختار داده (Data Structure) به شما جواب داد که این عضو در مجموعه وجود دارد احتمال دارد که وجود نداشته باشد. اما اگر بگوید وجود ندارد، قطعاً درست است. بر این اساس خطای مثبت داریم ولی خطای منفی امکان پذیر نمی‌باشد.احتمالا شما هم مثل من گیج شدید :) فرض کنید ما یک برگه کاغذ داریم که فقط و فقط مشخصات داده‌هایی که وارد میشن را می‌نویسیم دقت کنید ما در مورد داده‌های که خارج میشن چیزی نمی‌نویسیم. به این معنی که ممکنه یک داده‌ای وارد شده باشه و بعد هم خارج شده باشه و ما فقط زمان ورود اسمش را ثبت کردیم. بزارید با یک مثال پیش بریم. فرض کنید متغیرهای X,U,A,H وارد شدند. حالا اگر یک نفر از ما سوال کنه که داده X داخل لیست هست یا نه؟ ما چه جوابی می‌تونیم بدیم؟ همونطور که شما هم دارید حدس می‌زنید، درسته ما می‌تونیم بگیم X در لیست وجود داره اما این را هم در نظر داشته باشید که یک احتمال هم هست که متغیر X توی لیست نباشه و خارج شده باشه و از اونجایی که ما فقط و فقط اسامی ورودی ها را یادداشت می‌کنیم این توضیح در مورد خطای مثبت و خطای منفی درست هست. توجه داشته باشید ما نمی‌رویم داخل مجموعه‌ای که عنصرها داخلش ذخیره شدند جست و جو انجام بدیم و ببینیم آیا هنوز عنصر وارد شده هست یا نه، ما فقط یک لیست ثبت نامی یا همون برگه کاغذ را داریم که فقط و فقط لیست ورودی ها را داخلش می‌نویسیم. مثلا ما نمی‌رویم داخل دانشگاه تک تک اتاق اساتید را بررسی کنیم و دنبال آقای X بگردیم. بجای این کار فقط لیست اسامی وارد شده درب ورودی را چک می‌کنیم.حالا بیاید دنبال Y بگردیم و خب نتیجه جست و جو به ما میگه که Y در لیست نیست. در این حالت ما قطعا می‌تونیم بگیم که Y وجود نداره چرا؟ چون اصلا وارد نشده هنوز تا اسمش توی کاغذ ما ثبت بشه.یک سوال مهمی که پیش میاد این هست که این ساز و کار به چه دردی می‌خوره و چه کاربردی داره؟ کجاها می‌تونه باعث کاهش افزونگی و افزایش سرعت بشه؟با این مقدمه بریم سراغ معرفی ساختار داده‌های احتمالاتی و بلوم فیلتر و کاربردش در برنامه نویسیتعریف Bloom filterاحتمالا می‌دونید که جدول درهم سازی(hash table) چطور کار می کنه؟ اگر نمی‌دونید پیشنهاد می‌کنم یک سری به ویکی بزنید.در علوم رایانه، جدول درهم‌سازی یا جدول هش نوعی ساختمان داده است که مقدارهایی[۱] که باید ذخیره شوند را به وسیله تابع هش (درهم سازی) با کلیدهای ویژه‌ای مرتبط می‌سازد. عملیات اولیه‌ای که این جدول تسهیل می‌کند عمل مراجعه است. به این معنی که کاربر می‌تواند با سرعتی کارآمد داده مورد نظرش را در آن بیابد. در جدول‌های هش همچنین افزودن داده‌های جدید در زمان کم امکان‌پذیر است. زمان لازم برای جستجو و افزودن وابسته به نوع جدول و میزان داده‌ها هستند. این زمان می‌تواند با انتخاب جدول مناسب به مرتبه زمانی O(1) برسد. وقتی شما یک داده جدید در یک آرایه یا لیست ساده وارد می کنید، index همون مکانی که داده در آن قرار داده می شه از روی داده ای که داره تشخیص داده نمی‌شه. این به این معنی هست که ارتباط مستقیمی بین index و مقدار ذخیره شده در اون خونه از آرایه وجود ندارد.به همین دلیل اگر شما نیاز داشته باشید که یک مقدار را در آرایه جست و جو کنید، مجبور خواهید شد که همه Index ها را جست و جو کنید تا داده مورد نظرتون را پیدا کنید. اما در جدول درهم‌ساز شما key یا index را توسط هش کردن مقدار یا value تشخیص می دید. بعد این مقدار را در این index از لیست قرار می دید. به این معنی که key از روی مقدار value تشخیص داده می‌شه و هر زمانی شما نیاز به بررسی اینکه آیا value موجود هست یا نه داشته باشید شما فقط مقدار value را hash‌ می‌کنید و بعد بر اساس key جست وجو می‌کنید که توی تصویر زیر نشون داده شده. این خیلی سریعتر هست و مرتبه الگوریتم نیز O(1) است که خب خیلی سریع‌تر از O(n) است.نحوه عملکرد جدول درهم سازی یا hash tableخب تا اینجا مقدمات اصلی یا بهتره بگم پیش نیازهایی در مورد بلوم فیلتر را با هم بررسی کردیم و دیگه رسیدیم به قسمت های ساده تر و اصلی، بزارید با یک مثال کمی ملموس‌تر توی دنیای برنامه نویسی جلو بریم. بیاید در نظر بگیریم که یک لیست بزرگی از پسوردهای ضعیف وجود دارد و آن‌ها روی برخی از سرورهای remote ذخیره شده‌اند. امکان لود همه پسوردها بصورت فوری در حافظه memory/RAM به خاطر فضای کم وجود ندارد. هر زمان یک کاربر پسورد خودش را وارد می‌کند شما می‌خواهید بررسی کنید که اگر پسورد ضعیف بود به کاربر یک هشدار بدید. چه کار می‌تونید بکنید؟ در نظر بگیرید که شما لیست پسوردهای ضعیف را دارید، شما می تونید این‌ها را در یک جدول درهم ساز یا چیزی مشابه ذخیره کنید و هر زمان که می‌خواهید بررسی کنید، به جای جستجوی داده اصلی شما می توانید چک کنید که آیا هیچ گزینه متناظری وجود دارد یا نه. این تناظر یا تشابه ممکن است سریع باشد اما هزینه جست و جوی آن روی دیسک یا روی شبکه در یک سرور ریموت ممکنه زیاد یا باعث کندی باشه. فراموش نکنید که شما این کار را برای هر پسوردی که توسط کاربر وارد میشه باید انجام بدید. چطور میشه هزینه این کار را کاهش داد؟ بلوم فیلتر میتونه به ما کمک کنه. اما چطوری؟ بریم ببینیم بلوم فیلتر چطور کار می‌کنه. طبق تعریف بلوم فیلتر می‌تونه یک مقدار را در حالت‌های “احتمال وجود آن در مجموعه است” یا “قطعا در آن مجموعه نیست” بررسی کند. تفاوت ظریف بین احتمالا و قطعا نه در اینجا بسیار مهم است. به خاطر این جمله “احتمالا در مجموعه است“ می‌باشد که چرا این ساختار داده‌ها احتمالاتی نامیده می‌شوند. و با تعریف هایی که شده بدین معنی است که مثبت کاذب امکان پذیر هست اما منفی کاذب غیر ممکن است. عجله نکنید، در ادامه با مثال عملی می‌بینیم که دقیقا اینا یعنی چی. بلوم فیلتر اساسا شامل یک بردار بیتی یا لیست بیتی(یک لیست شامل مقدار بیت فقط 0 یا 1) به طول m، با مقدار اولیه 0 مانند شکل زیر است:مقداردهی لیست بیتی بلوم فیلتر برای اضافه کردن یک آیتم به بلوم فیلتر، ما اول آیتم مون را به k تابع هش مختلف می دهیم هر تابع هش یک عدد به ما می‌دهد که ما متناظر با هر عدد توی آرایه‌مون مقدار اون خونه را برابر 1 قرار می‌دهیم. همونطور که می‌تونید ببینید در جدول هش ما از یک تابع هش تکی استفاده کردیم و به عنوان نتیجه فقط یک index تکی به عنوان خروجی داشتیم. اما در این مثال از بلوم فیلتر ما از تابع هش چندگانه (k تعداد توابع هش) استفاده می‌کنیم که خروجی چندگانه نیز خواهیم داشت.خروجی تابع هش چندگانه برای کلمه geeksهمونطور که در تصویر بالا مشخص هست برای ورودی آیتم geeks ما سه تابع هش داریم که هر تابع یک مقدار به ما بر می‌گردونه که در این مثال مقدار 1 ,4,7 هست یعنی خونه شماره 1 , 4 و 7 را از صفر به 1 تغییر میدهیم که ما آن ها را مشخص کردیم.خروجی تابع هش چندگانه برای کلمه nerdبه همین ترتیب برای ورودی دیگری به نام nerd توابع هش به ما ۳ خروجی 3,4,5 را می‌دهد. شاید متوجه شده باشید که index شماره 4 یا همون خونه شماره 4 قبلا با کلمه geeks علامت گذاری شده(از صفر به 1 تغییر داده شده). خب تا اینجا با بردار بیتی خودمان را با دو وردی پر کرده ایم. و حالا می تونیم بررسی کنیم که آیا مقدار مورد نظر ما داخل آن وجود دارد یا نه. اما چطوری؟ خیلی ساده هست. ما یک جدول هش ایجاد کردیم. ورودی مورد نظرمون که می‌خواهیم جست و جو کنیم را با سه تا تابع هش می‌کنیم و نتیجه سه تا تابع که سه تا عدد است را بررسی می کنیم که کدام index‌ها یا ساده‌تر کدوم مکان‌های آرایه میشه. مثلا اگر بخواهیم ببینیم کلمه nerd وجود دارد یا نه کافیه ابتدا این کلمه را بدیم به سه تابع هش و خروجی که سه تا عدد است را داخل آرایه تک بعدی بررسی کنیم. که خب هر سه تا خونه مقدارش برابر 1 است یعنی این عنصر احتمالا وجود دارد.جستجوی کلمه cat در بلوم فیلتردر ادامه بزارید جست و جو برای کلمه cat را انجام دهیم که خروجی سه تابع هش این کلمه برابر 1 ,3,7 هست که می‌تونیم ببینیم که مقدار هر سه تا خونه 1,3,7 برابر 1 هست که این به این معنی است که ما می‌توانیم بگوییم “احتمالا کمله cat در لیست وارد شده است”. اما وارد نشده است!! پس این خطا از کجا است؟ در واقع هیچ خطایی رخ نداده. به این اتفاق میگن خطای مثبت کاذب که در ادامه نحوه جلوگیری از این اتفاق را هم توضیح می‌دهم. بلوم فیلتر به ما می گوید که این نشان می دهد که شاید کلمه cat قبلا وارد شده بوده است زیرا همه خانه‌های index مربوط به خروجی سه تابع هش برای کلمه cat برابر 1 است(حتی با داده های مختلف دیگه). خب این کجاش مفیده و بدرد می‌خوره؟ بیاید در نظر بگیریم اگر خروجی توابع هش برای کلمه cat به جای 1,3,7برابر 1,6,7 می‌بود، در این صورت چی می‌شد؟ ما می تونستیم ببینیم که Index مربوط به 6 برابر 0 است. که به این معنی هست که با هیچ ورودی، قبلا این خونه علامت‌گذاری(تغییر از صفر به 1) نشده. که به این معنی است که کلمه cat هیچ وقت وارد نشده است. این نحوه کار بلوم فیلتر است که می تواند به ما بگوید “دقیقا”داده در لیست وجود ندارد. خب به طور خلاصه:اگر ما برای یک مقدار جست و جو کردیم و نتیجه هر هش‌ای را پیدا کردیم که مقدار آن برابر 0 بود ما می‌توانیم با اطمینان بگوییم که در لیست وجود ندارد.اگر همه indexهای خروجی توابع هش برابر 1 باشد آنگاه ممکن است مقدار جست و جو شده وجود داشته باشد.در واقع در برخی شرایط ما می‌توانیم به جای جستجوی موجود بودن گزاره را برعکس کنیم. و دنبال نبودن یا شامل نشدن بگردیم و خیلی سریع‌تر به جواب برسیم. خب بزارید برگردیم به مثال پسورد که ابتدا در موردش صحبت کردیم. اگر ما بررسی پسوردهای ضعیف را با این نوع از بلوم فیلتر پیاده سازی کنیم، ابتدا، ما بلوم فیلترمان را با یک لیست از پسوردهای ضعیف که به ما یک بردار بیتی می‌دهد که برخی از indexهای آن با 1مقدار دهی شده و مابقی با 0 مقدار دهی شده است، ایجاد می‌کنیم. از آنجایی که اندازه بلوم فیلتر نمی تواند خیلی بزرگ باشد و یک اندازه ثابت دارد، این می تواند به راحتی در حافظه ذخیره شود حتی در صورت نیاز می‌تواند در سمت client ذخیره شود.به همین دلیل است که بلوم فیلتر بسیار space-efficient است. در حالی که یک جدول هش نیاز به داشتن اندازه دلخواه بر اساس داده‌های ورودی دارد، بلوم فیلترها می توانند با اندازه ثابت به خوبی کار کنند و این یعنی عملیات جستجو خیلی سریع‌تر و ساده‌تر خواهد بود.بنابراین هر بار که کاربر پسورد خود را وارد می کند ما آن را به توابع هش می‌دهیم و خروجی توابع هش که مکان خانه‌های آن در بردار بیتی است را بررسی می‌کنیم که وجود نداشته باشد. اگر پسورد به اندازه کافی قوی باشد بلوم فیلتر به ما نشان می دهد که پسورد دقیقا در لیست پسورد های ضعیف نیست و نیازی نیست که ما کوئری سمت سرور بزنیم. اما اگر پسورد ضعیف بود و به ما جواب مثبت(ممکن است مثبت کاذب باشد) داده شود، ما یک درخواست سمت سرور برای بررسی لیست اصلی می کنیم. همانطور که می‌بینید اغلب اوقات ما حتی نیاز به درخواست از سرور و یا از دیسک برای چک کردن لیست نداریم که این باعث بهبود قابل توجهی در سرعت نرم افزار می‌شود چرا که صرفا یک بردار بیتی را بررسی می‌کنیم و سمت دیتابیس کوئری نمی‌زنیم. در صورتی که بخواهیم بردار بیتی را در سمت سرویس گیرنده یا client ذخیره کنیم، هنوز هم می توانیم آن را در حافظه سرور بارگزاری کنیم و حداقل برخی از زمان جست و جوی دیسک را صرفه جویی کنیم. به بیان ساده‌تر به جای مراجعه به لیست بلندی از پسوردها و جست و جو داخلشون که از مرتبه n یا دیگر مرتبه ها است ما از روی پسوردها یک بردار بیتی درست می‌کنیم و برای بررسی کلمه مورد نظر را هش می‌کنیم مثلا ۳ تا خروجی میده فقط ۳تا خونه بردار بیتی را بررسی می کنیم که سرعت کار ما را خیلی بالا می‌بره.همچنین در نظر بگیرید که اگر نرخ خطای مثبت بلوم فیلتر شما 1% باشد به این معنی است که در میان هزینه های مراجعه به سرور یا دیسک، تنها 1% از کوئری‌های ما با خطا مواجه خواهد شد و ۹۹درصد دیگر سمت سرور نخواهند رفت. بد نیست نه؟عملیات‌های بلوم فیلتریک بلوم فیلتر ساده از دو عملیات test (یا بررسی) و add (یا اضافه کردن) پشتیبانی می‌کند. Test برای چک کردن اینکه آیا یک عنصر در مجموعه وجود دارد یا نه و عملیات add هم برای اضافه کردن یک عنصر به مجموعه.به نظرتون امکان حذف کردن یک ایتم از بلوم فیلتر وجود دارد؟ قبل از ادامه دادن یکم روی جواب تون فکر کنید.قبل از جواب دادن به سوال بالا بیاید یک مثال بصورت عملی بررسی کنیم. فرض کنید در بردار بیتی دو کلمه geeks و nerd را اضافه کردیم:حالا ما میخواهیم عنصر geeks را از بلوم فیلتر حذف کنیم. بنابراین اگر ما 1,4,7 را از بردار بیتی حذف کنیم که قبلا توسط geeks علامت گذاری شده بودند، و ما مقدارشونا به 0 تغییر بدیم چه اتفاقی می افتد؟به سادگی می‌تونید ببینید که اگر ما در ادامه کلمه nerd را جست و جو کنیم همانطور که می‌بینید Index شماره 4 برابر 0 هست و این به ما می‌گوید که دقیقا nerd در لیست وجود ندارد در حالی که اشتباه است. این بدین معنی است که امکان حذف در بلوم فیلتر وجود ندارد.پس راه حل چیه؟ در واقع توی بلوم فیلتر ساده چنین امکان وجود نداره. اما اگر واقعا به چنین چیزی نیاز دارید می تونید از یک نسخه تغییر یافته بلوم فیلتر به نام Counting bloom filter استفاده کنید. ایده ساده است. به جای مرتب سازی یک بیت تکی از مقدارها، ما یک مقدار integer را ذخیره می کنیم و بردار بیتی ما بردار integer خواهد بود. قابلیت حذف کردن باعث افزایش اندازه و هزینه ما خواهد شد. در این حالت به جای علامت گذاری یک مقدار بیت با 1 هنگام ورود داده، ما مقدار integer را به مقدار 1 افزایش می دهیم و اگر داده جدیدی وارد بلوم فیلتر کردیم یک واحد دیگه افزایش می‌دهیم مثلا مقدار خانه اگر 1 بود با افزایش مجدد به 2 تغییر داده می‌شود و در هنگام حذف کلمه یک واحد از خانه‌هایی خروجی توابع هش کم می‌کنیم. برای بررسی اینکه یک عنصر موجود هست یا نه کافی هست که عنصر را هش کنیم و خانه هایی را که بررسی میکنیم مقدارشون بیشتر از 0 باشه. که قابلیت حذف را ما فعلا نیاز نداریم و بیشتر از این هم بهش نمی‌پردازیم.اندازه Bloom filter و تعداد توابع Hashشاید به این فکر کرده باشید که اگر اندازه بلوم فیلتر کوچک در نظر گرفته بشه ممکنه سریع همه خونه های آن برابر 1 بشه و بعد از این هر کلمه‌ای چه در لیست باشه چه نباشه را بررسی کنیم جواب مثبت برگردانده بشه. بنابراین اندازه بلوم فیلتر خیلی مهم است. در اینجا اگر اندازه بلوم فیلتر بزرگ انتخاب شود ما جواب های مثبت کاذب کمتری داریم و اگر اندازه کوچک باشد ما جواب های مثبت کاذب بیشتری خواهیم داشت. اینجا یک موضوع جدید خواهیم داشت با عنوان نرخ خطای مثبت کاذب. پارامتر مهم دیگر این است که چه تعداد تابع هش نیاز داریم؟اینجا است که تحقیقات دانشگاهی می‌تواند به کمک ما بیاد(این موضوع را برای این اشاره کردم که بعضی از دوستان فکر می‌کنند دانشگاه در مقطع تحصیلات تکمیلی به چه دردی میخوره؟ دقیقا به درد کارهای تحقیقاتی می‌خوره که اینجا یک نمونه‌ش را اشاره می‌کنم).طبق مقاله ارائه شده که نتیجه آن در شکل زیر نشان داده شده می‌توانید ببینید که اندازه بلوم فیلتر و تعداد توابع هش به صورت مناسب چقدر هست:در نمودار بالا با افزایش تعداد تابع هش یعنی k، نرخ خطا که با p نشان داده شده کاهش پیدا می‌کند. در واقع ما می‌توانیم نرخ خطای کاذب مثبت P را بر اساس اندازه بلوم فیلتر که با m و تعداد تابع هش که با k نشان می‌دهیم، اگر تعداد عنصر ورودی ما(مثلا تعداد پسوردها) برابر n باشد، می‌توانیم بصورت زیر محاسبه کنیم:محاسبه احتمال خطای کاذب برای بلوم فیلتراگر به ریاضیات علاقه ای ندارید نگران نباشید :) در واقع ما فقط نیاز داریم که مقدار m و k را مشخص کنیم. اگر نرخ خطای مثبت کاذب ما برابر p باشد و تعداد داده‌های ورودی برابر n باشد ما می تونیم از فرمول های زیر برای محاسبه پارامترهامون استفاده کنیم:محاسبه اندازه بلوم فیلتر m و تعداد توابع هش مورد نیاز kنکته دیگه که باید توجه کنید این هست که هدف استفاده از بلوم فیلتر جست و جوی سریعتر هست، ما نمی توانیم از توابع هش با سرعت پایین استفاده کنیم. بنابراین توابع هش رمزنگاری Sha-1 و MD5 انتخاب خوبی برای بلوم فیلترها نیستند. توابع هش سریعتری پیاده سازی شدن که می‌توانید ازشون استفاده کنید. مثلا murmur fnv HashMix انتخاب های بهتری هستند. کاربردهابلوم فیلتر برای بررسی عضو داخل یک مجموعه است. مثال ساده بلوم فیلتر برای کاهش هزینه مراجعه به دیسک یا شبکه برای کلیدهای ناموجود است. همونطور که ما می‌توانیم ببینیم بلوم فیلترها می توانند یک کلید را در O(k) جست و جو کنند که k تعداد تابع هش است. این بسیار سریعتر هست که کلید ناموجود را جست و جو کنیم. اگر عنصر در بلوم فیلتر نباشد پس ما نیازی به جست و جوی پر هزینه نداریم. از طرف دیگه اگر عنصر در بلوم فیلتر موجود باشد ما جست و جو را انجام می‌دهیم و می‌توانیم انتظار داشته باشیم که در برخی موارد ما نرخ خطای مثبت کاذب(false positive rate) داشته باشیم. و عنصر موجود نباشد. در ادامه برخی مثال‌های استفاده از بلوم فیلتر را معرفی می‌کنیم.من در این قسمت در مورد یکی از کاربردهایی که برای پایان نامه ام درگیرش بودم کمی توضیح می‌دهم که چطور استفاده از بلوم فیلتر توی کاهش سربار اطلاعات تبادل شده در شبکه‌های تحمل پذیر تاخیر میتونه مفید باشه.خیلی خلاصه شبکه های تحمل پذیر تاخیر یا DTN شبکه هایی هستند که بر خلاف شبکه های سنتی که ارتباط end-to-end اگر با تاخیر مواجه بشه ارتباط را خاتمه میده می تونن تاخیر را تا حدود زیادی تحمل کنند. در صورت نیاز به مطالعه بیشتر اینجا را می‌توانید مطالعه کنید. در این شبکه ها دو تا گره(node) که همون دستگاه‌ها هستند حالا می‌تواند یک ماشین مجهز به wifi توی بزرگراه هوشمند باشه یا اینکه یک ماهواره در مدار زمین باشه وقتی با همدیگه مواجه می‌شوند باید بسته‌هایی که در بافر خودشون دارند را با یکدیگر مبادله کنند. یک راه ساده انتقال کل بافر هر نود برای نود دیگه است که خب سربار خیلی زیادی داره و از طرف دیگه ممکنه یک نود برخی از پکت‌ها را قبلا توسط بقیه نودها دریافت کرده باشه مجددا دریافت کنه و باعث سربار اضافی بشه. برای کاهش سربار و جلوگیری از ارسال تکراری پکت ها استفاده از بلوم فیلتر یک راهکار خوبی است. به این صورت که ابتدا هر نود یک بردار بیتی(بلوم فیلتر) از بسته هایی که دارد ایجاد می‌کند که حجم بسیار پایینی دارد و آن را برای نود دیگه ارسال می‌کند. و نود قبل از ارسال بسته‌ها چک ‌می‌کند که آیا داخل بلوم فیلتر دریافتی وجود دارند یا نه. اگر بلوم فیلتر جواب منفی داد یعنی بسته‌ها در نود دیگر وجود ندارند و باید ارسال بشوند و اما اگر بلوم فیلتر اعلام کنه که بسته موجود است از ارسال آن جلوگیری میشه. که این می‌تواند باعث کاهش سربار تبادلات شود.مثال های استفاده از بلوم فیلتر:برای هشدار به کاربران در مورد ضعیف بودن پسورد که در بالا توضیح داده شد.برای جلوگیری از دسترسی کاربران به سایت های مخرببرای بررسی اینکه چه کاربرانی قبلا از سایت شما بازدید کردند بر اساس IP هاشون.برای بررسی اینکه چه تعداد از کاربران محتوای سایت شما را خوانده اندجالبه بدونید که خود سایت Medium هم از ساختار داده بلوم فیلتر استفاده می‌کنه که توضیحات کامل ترش را اینجا می‌تونید مطالعه کنید.اگر هم علاقه دارید به صورت عملی با بلوم فیلتر بازی کنید و دقیق تر درکش کنید اینجا می‌تونید یک نسخه تحت وب را تست کنید.در پست های آینده سعی می‌کنم یک مثال کاربردی را بصورت کدنویسی پیاده سازی کنم و شرح بدم.در پایان امیدوارم این مطلب مفید بوده باشه براتون. اگر سوالی داشتید حتما بپرسید. این مطلب هم اولین نوشته من هست اگر در مورد متن اشکالی/انتقادی/پیشنهادی داشتید خوشحال می‌شم بیان کنید.منابعhttps://en.wikipedia.org/wiki/Bloom_filterhttps://hackernoon.com/probabilistic-data-structures-bloom-filter-5374112a7832https://www.geeksforgeeks.org/bloom-filters-introduction-and-python-implementation/https://www.semantics3.com/blog/use-the-bloom-filter-luke-b59fd0839fc4/https://medium.com/better-programming/probabilistic-data-structures-bloom-filter-5374112a7832 حسین مسعودی حسین مسعودی Fri, 23 Aug 2019 21:31:29 +0430