Arsham's Tech Mastery

جلسه هام با یه سری از دوستان داره به جاهای جالبی میرسه، مثلا چندوقت پیش داشتم کد یکیشونو ریویو میکردم و به جایی رسیدم که واقعا نیاز بود cherry pick کنیم (چری پیک چیه؟) یکی از کامیت های خیلی قدیمی یکی برنچ هارو آوردم گذاشتم سر یه برنچ دیگه، بعدش سافت ریست اش کردم و یه خورده تغییرش دادم و کلی کارم راه افتاد. چری پیک رو از قبل بلد بودم، ولی تو این چند سال تو کار واقعی پیش نیومده بود برام. در کل جلسات Pair programming, Knowledge sharing, English technical discussion, etc. خوبی داشتیم، حالا این پست فعلا اینجا باشه، یه سلسله پست داریم و بعدش میخوام یه مشورت ازتون بگیرم.

چند وقت پیش یکی از دوستان پرسیده بود:

رفقا به نظرتون با گو میشه یه رباتی مثل رباتای دانلودر ساخت ؟

که جوابشو دادم (بله، به راحتی میشه) و قول دادم دانلودر پادکرایب رو اپن سورس کنم، آموزش دانلود مالتی پارت زیاد هست تو وب، ولی کد نهایی زیاد جالب نیست معمولا و آموزشی که پراگرس دانلود هم نشون بده ندیدم. https://github.com/arshamalh/multipart-golang-downloader فعلا این دویست و خورده ای خط رو اپن سورس کردم، که فایل رو به بخش های مختلف میشکنه و به صورت همزمان توسط چند گوروتین دانلودش میکنه، در آخر هم تیکه (chunk) هارو با هم ترکیب (merge) میکنه و مینویسه توی فایل. یه استفاده کوچیکی هم از پکیج کبری (cobra) شده. نکته مهم:

این کد بهترین کد نیست، ایراداتی داره، فقط چندتا نکته مهم داره در رابطه با دانلود همزمان و خوندن پراگرس زمانی که داریم دانلود میکنیم (با استفاده از io.Copy و bytes.Buffer{})

#مقدماتی #ضروری یکی از پایه ای ترین ابزار هایی که برنامه نویس ها لازمه بلدش باشن گیت (#git) هست، که خوشبختانه انقدر معروف هست که اکثرا باهاش آشناییم ولی یه سری از دوستانی که تازه برنامه نویسی رو شروع کردن ممکنه از وجود و اهمیت همچین ابزاری مطلع نباشن. گیت یه ابزار کنترل نسخه هست، یعنی اگه درست ازش استفاده کنیم، به ما کمک میکنه که ذره ذره توسعه نرم افزارمون رو مدیریت کنیم، به ما کمک میکنه که تغییراتمون رو دسته بندی کنیم، آزادانه کدمون رو تغییر بدیم و اگه تغییر جدیدمون مشکل داشت، به نسخه های قبل برگردیم. همچنین به ما کمک میکنه که به صورت تیمی روی یک کد مشترک کار کنیم و... خلاصه که از مزیت هاش هرچی بگم کم گفتم. گیت یه ابزاره، اما از طرف دیگه سایت هایی وجود داره مثل گیتهاب، گیتلب و... که میتونن به عنوان مخزن نگهداری کد های شما استفاده بشن. گیت و گیت هاب یکی نیستن، اما میتونن با هم کار کنن. اولین چیزی که من همیشه از شاگرد هام میخوام اینه که یه اکانت گیتهاب بسازن و هر پروژه ای حتی تستی رو هم با کامیت و... درست پیش ببرن. در آخر آیا دوست دارید یه آموزش برا گیت ضبط کنم؟ ⚡️ آره 🕊 نه، تو کامنت آموزش خوب پیشنهاد میدم

تجربه و سابقه متفاوتن، حرفی که اکثرمون شنیدیم و بعید میدونم کسی بتونه با قاطعیت ردش کنه، اما بازم میگن "فلان سال تجربه" در حالی که واحد سنجش تجربه اصلا زمان نیست (هرچند که به زمان هم وابسته است)، فرض بگیریم که یکی ده ساله داره یه کار روتین و بدون چلنج انجام میده، و یکی دیگه نه تنها تو کارش همیشه در حال تجربه کردن چالش های جدیده، بلکه تو تایم های خالی اش هم مدام در حال مطالعه و... است، کدومشون برای همکاری به چشمتون جذاب تر میاد؟ <<-------->> آدم "با تجربه"، کسیه که مشکلات متفاوت رو "تجربه" کرده باشه، به قول یه دوستی تو نتفلیکس که میگفت:

Seniority is about the problems you've seen.

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

کمّی کردن این پارامتر کار ساده ای نیست، ولی بازم آدم با تجربه ای که سافت اسکیل های خوبی هم داشته باشه میتونه بقیه آدم های با تجربه رو تشخیص بده، ولی خب توضیحش مفصله که چطور و بماند. <<-------->> یه دفاع هم کنم از این اشتباه رایج، قبول داریم که نسبت تجربه و سابقه خطی نیست، اما برعکس هم نیستن و رو هم تاثیر دارن، و برای منابع انسانی هم یه فیلتر اولیه سریع و نسبتا کم هزینه تره. و خب از اونجایی که برنامه نویس ها هم معمولا آدمای مطالعه گر، کنجکاو و باهوشی اند، پس میشه گفت خیلیامون با گذشت زمان یه پیشرفت هایی داریم... (وقتی نرخ پیشرفت تفاوت زیادی نداشته باشه، سال میتونه معیار باشه) یه نکته دیگه هم که نباید جا بیوفته، گذشت زمان حتی اگه موجب افزایش دانش نشه، اما رو بینش فرد هم تاثیر میزاره، البته بازم خیلی به شخص اش بستگی داره. پیشنهاد میکنم راجع به دانش و بینش هم بخونید: https://academybrice.com/آشنایی-با-دانش-و-بینش/ #hr #resume #تجربه

گاها پیش اومده که دوستانم بهم گفتن

یه سوال مبتدیانه|بچهگانه|احمقانه بپرسم؟

سوال احمقانه نداریم، سوالای شما ارزشمند و شدیدا محترمن، هر کسی که در گذشته به سوالاتتون احترام نزاشته، تمسخر کرده یا‌...، مشکل از اون بوده نه شما. عادت کنید بپرسید، زیاد پرسید، سوال خوب بپرسید، سوال خوب؟ حرف خودمو نقض کردم؟ نه، منظورم از سوال خوب سوالاییه که دغدغتون رو شفاف تر بیان کنه و شمارو زودتر به جواب برسونه (که نیازمند تکنیک و تجربست)، ولی در هر صورت سوال اوکیه. <<------>> شخصا سعی کردم اینو تو خودم پرورش بدم که سوالات بقیه رو قضاوت نکنم، حتی اگه ده بار یه سوالی که برای من سادست تکرار بشه، هر ده بارش خلاقیت های متفاوت به کار میبرم و سعی میکنم زاویه دید های جدیدی پیدا کنم تا جایی که بالاخره بدونم موفق شدم مطلب رو برسونم. ساختار مغز و شیوه یادگیری و تربیتی ما یکی نبوده، چیزی که برای من بدیهی شده ممکنه برای یکی سخت باشه، و برعکسشم ممکنه و اتفاقا وجود داشته. <<------>> مثلا یادمه یه زمانی درس طراحی اجزا ۲ رو همه بچه ها پروژه رو تکمیل کرده بودن، بعد من هنوز نمیتونستم پروژه رو استارت بزنم! به معنای واقعی داشت اشکم در میومد! شیوه تدریس استاد به یادگیری من نمیخورد. بعد یکی از دوستام جزوه هاشو بهم داد و خوندم و یادش گرفتم، بعدش من تو چند روز نه تنها پروژه رو کامل زدم و امتحانش هم بالاترین نمره شدم، بلکه پروسه اش هم اتومیت کردم و پروژه سه نفر دیگرم زدم و یه پولی هم در آوردم 😅 نظر شخصی: گاهی وقتا یادگیری مثل قفل و کلیده، هر مغزی یه کلیدی میخوره، شما باید کلید خودتونو پیدا کنید (هر کسی شیوه یادگیری خودشو داره)، یا وقتی توضیح میدید، کلید ذهن طرف مقابل رو.

بالاخره داکرولر رو به مرحله ریلیز آلفا رسوندیم 🥳️️️️️️😍️️️️ داکرولر یه ابزاره که شما میتونید به کمکش، از طریق مسنجر های مختلف (فعلا فقط تلگرام) داکرتون رو کنترل کنید، ایمیج هارو لیست کنید، حذف کنید، تگ بزنید، کانتینر هارو لیست کنید، حذف کنید، استاپ و استارت کنید، حتی لاگ و مصرف منابع کانتینر هارو هم به صورت لحظه ای (real-time) ببینید. اینا قابلیت های فعلیشه، چیزای باحال تری هم قراره در آینده بهش اضافه کنیم. استارت این پروژه رو پارسال زدم، ولی به دلیل مشکلاتی که هممون ازش مطلعیم متاسفانه متوقف شد، تا اینکه با همکاری دوست خوبم مبینا تصمیم گرفتیم دوباره استارتش بزنیم. ورژن فعلی آلفا (Software release life cycle) هست و آماده پروداکشن نیست، یه خورده تغییرات دیگه و تست های متوالی و مختلف نیاز داره تا آماده پروداکشن بشه، هدف این ریلیز آلفا بیشتر درخواست مشارکت (حتی در حد نظر راجع به کلیت ایده) هست. نظرتون بسیار برام ارزشمند و مهمه. از نداشتن تست و نامناسب بودن ساختار ephemeral session مطلعم و در اولویت انجام شدن هستن. https://github.com/arshamalh/dockeroller/releases/tag/v0.1.0-alpha

یه چیزی که متاسفانه خیلی باهاش رو به رو میشم، یکدست نبودن راه حل ها در کل یک نرم افزاره، مثلا فکر کن تو یه پروژه، از دوتا کتابخونه مختلف برای لاگ انداختن، orm، اتصال به یه api خاص و... اونم به صورت کاملا نامنظم استفاده بشه، مخصوصا وقتی که هر دوی اونا ویژگی های مورد نیاز پروژه رو تامین میکنن. جزئی تر بخوام بگم، فکر کن برای لاگ انداختن توی پروژه گولنگی، یه جاهایی از zap و یه جاهایی از zerolog استفاده بشه. البته شما ممکنه با یه separation خوبی دیتابیس ها و orm های مختلف رو تو پکیج خودشون ایزوله کنید و با کمک اینترفیس ها به آبجکت های مختلف inject کنید. بحثم حتی از اینم فراتره، حتی استایل کامنت های شما، شیوه نامگذاری، ساختار و فولدربندی پروژه و... هم بهتره یکدست (uniform) باشه. حکم نهایی نیست، میتونه یکدست نباشه، اما یکدست نبودن باعث گیجی خودتون و بقیه در آینده میشه. یه مثال ملموس تر بزنم، فکر کن یه ماشینی باشه که کل ماشین مشکیه، در سمت شاگرد کلا قرمزه 😅 این ماشین قطعا نو نیست و نیازمند نقاشی مجدده!

سوییچ کیس، چند تا کیس؟ یه وقتایی لازم میشه که هندلر های مختلف رو به کلید های مختلف وصل کنیم، بعضی وقتا به صورت داینامیک و بعضی وقتا به صورت استاتیک. مثلا داخل بعضی از فریمورک های وب (مثلا اکو)، از مپ برای رجیستر هندلر ها به صورت داینامیک استفاده میشه. اگرچه که سوییچ کیس پرفورمنس بهتری نسبت به مپ داره ولی فقط برای موارد استاتیک کاربرد داره، یعنی وقتی که دقیقا میدونیم چه هندلری میخوایم و تو کد عینا مینویسیمش. یه جاهایی هم مثل فایبر ساختار پیچیده تری دارن برای رجیستر هندلر ها. حالا سوالی که برا خودم پیش اومده، واقعا سوییچ کیس مثل چیزی که تو عکس گذاشتم اوکیه؟ به نظر شما این تعداد بالای کیس های مختلف ایرادی داره؟ چرا؟ میشه بهتر نوشتش؟ چه از نظر تمیزی و چه پرفورمنسی؟ (پیچیدگی سوییچ کیس O(1) هست، مثل مپ و ایندکس اسلایس، ولی در ضریبشون تفاوت هایی هست که تو بیگ اُ نمیاد) یه جا هم تو استک اورفلو نوشته بود با پنج هزار تا کیس چه مشکلی ممکنه پیش بیاد؟ که جالب بود برام. 🤔

https://github.com/go-joe/joe/commit/e159c3b95091deaf93481bd64c2b27156701960b کامیت جالبی بود، چرا باید روی یک کاستوم تایپ که تابع هست، متد نوشت!؟ اینجوری شده که خودش تابعه ها، ولی اگه کالش نکنی میتونی متد روشو کال کنی و اون متد روش که کالش کردی، خود تابع رو کال میکنه! بعد همین تایپ دلخواه، یه اینترفیس رو هم ایمپلیمنت میکنه. فکر میکنم اصلا خوانایی خوبی نداره، بازم ردش نمیکنم، ولی من سعی میکنم همچین کدی ننویسم. نظر شما چیه؟

برای رودمپ خیلی ازم سوال پرسیدن، نظرمو اینجا میگم، سایتایی هستن مثل Roadmap.sh، که البته استفاده ازش نکته داره که ممکنه خیلیا چنان مبهوت مپ خوشگلش بشن که نکته هاشو نخونن 😅 دو تا از نکته هاشو به نقل از بخش Frequently Asked Questions در زیر دیاگرام میگم و بعدش خودم جمع بندی میکنم.

Note: remember to make a lot of projects while you are learning to solidify your understanding of the concepts.

Should I learn everything listed on the Backend Roadmap? You may not need everything listed on this roadmap to get into the industry; every job is different and most of the jobs will require a subset of the items on the roadmap.

شما باید یه سری دانش پایه داشته باشید، یه سری مهارت های نرم، و یه سری دانش و مهارت های خاص اون شغل. یادگیری مسمتر از ویژگی های اصلی یه مهندس نرم افزاره، بنابراین طبیعیه که با عوض کردن شرکت، دانش خاص شغل جدیدی بدست بیارید. <<---->> مسیر پیشنهادی من برای بک اند: - یادگرفتن یه زبان (هر زبانی که دوست دارید و تا حدی بازار داره، گو، جاوااسکریپت، جاوا، و...) - تمرین الگوریتم های ساده و یادگیری دیتااستراکچر های اولیه (تا قبل گراف برا شروع کافیه) - یاد گرفتن دیتابیس های رابطه ای (relational) - گیت، گیت، گیت (خیلی مهمه، و خوب یادش بگیرید) - داکر (در حدی که بتونید باهاش کار کنید برا شروع کافیه) و بعدش شروع کنید پروژه بزنید، تو پروژه هاتون سعی کنید: - تست بنویسید - تمیز کامیت بزنید، اگه تیمی کار کنید که تصادفا هم مرج کانفلیک بخورید، مهارت حل کردنش ارزشمنده. - فرهنگ دوآپس رو دنبال کنید، اتومیشن و cicd به پروژتون اضافه کنید، پروژتون رو داکرایز کنید و ابزار های لاگینگ، مانیتورینگ، تریسینگ، مجموعا observablity رو استفاده کنید. - پروژتون رو مایکروسرویس کنید و با بروکر ها درگیر بشید. در تمام این مدت هم کد بخونید، هزاران پروژه اپن سورس وجود داره برای شما که کدشونو بخونید! و بعدش وارد بازار کار بشید، چالش های بازار کار با پروژه های شخصی خیلی متفاوته، سعی کنید این ورود به بازار کار زیاد طول نکشه و ایده آل گرا نباشید، قرار نیست همه چیزو بدونید، قراره بتونید به عنوان یه بخشی از سازمان کمک کنید که یه ارزشی خلق بشه. یه چیز فوق العاده مهم دیگه هم هست به اسم سیستم دیزاین System Design، بعد پروژه های مقدماتی شروع کنید راجع بهش بخونید، منم راجع بهش چندتا پست خواهم گذاشت. ردیس هم اگرچه که صرفا یه ابزاره، ولی همه جا هست 😅 و نمیشد بهش اشاره نکنم، همون تو استپ مقدمات اگه جاش بدید ضرر نمیکنید.

شعله ات رو چطور روشن نگه میداری؟ 🔥✌️🏼 گاها ممکنه برامون پیش بیاد که کارمون روتین بشه، به دامین کاملا مسلط بشیم، فیچر جدید، چلنج جدید و... نیاد و این وضعیت برامون خسته کننده باشه. شخصا تو این وضعیت، روش های زیر رو پیش میگیرم: - آموزش دادن (متن و مقاله نویسی، جلسه های منتورینگ و...) - مینی پروژه زدن (پروژه هایی که شاید هم به جایی نرسه، ولی یه جذابیتی داره اینکه یه چیزی دان میشه) - مطالعه (البته غیر دیجیتال، چشم و دوری از فضای مجازی و این داستانا) - امتحان کردن تکنولوژی های جدید و شاید امتحانشون تو مینی پروژه ها - گزینه محتاطانه و حساس: عوض کردن تیم یا کلا شرکت لطفا شما هم تجربه هاتونو برام بنویسید که چطور آتیشتون (شعله داخل موتور قلبتون که شمارو به جلو هل میده) رو روشن نگه میدارید 🔥😃 ××××× دلیل خاموشی آتیش ممکنه برن آوت شدن باشه، که در این صورت اگه برن آوت شدید باشه به روانشناس مراجعه کنید و اگر مدیر شایسته و خوبی دارید با ایشون هم مشورت کنید. ولی راجع به برن آوت های ساده تجربه ام این بوده که میشه مثلا یک (یا چند) مرخصی رو بچسبونید به آخر هفته و یه کار کلا متفاوت و حتی بیرون از دنیای کامپیوتر انجام بدید، کشاورزی، نجاری، کوه نوردی و... اینجوری اول هفته بعد کلا ریست میشید. البته این نسخه نیست، صرفا تجربه شخصیه.

چنل Healthy Software Developer یکی از بهترین چنل هاییه که محتوای منحصر به فردش رو خیلی دوست دارم. همونطور که از اسمش مشخصه، برخلاف بقیه چنل ها که تمرکزشون مهارت های تخصصیه، این چنل رو مهارت های نرم (#softskill) تمرکز کرده و اطلاعات با ارزشی ارائه میده. برای مثال هم یکی از ویدئو های خوبش رو میزارم: https://youtu.be/0EvRSD1-jII?si=D1Nx7RvP1IMOT-CA به عنوان کسی که مدیر های مختلفی داشتم و خودمم یه خورده تجربه مدیریت تیم دارم، فکر میکنم داشتن دانش مدیریت برای هر کسی که این تایتل (Tech lead) رو میگیره خیلی خیلی ضروریه و ضعف آموزش مدیریت برای افراد فنی تو بازار کارمون خیلی حس میشه. جمله ای که اولش میگه: Under pressure, management will often promote strong individual contributors to tech lead positions just out of fear of losing them when they're really not a good fit at all for being a tech lead. پیشنهاد میکنم این ویدئو رو ببینیم 😉🙌🏼 ---- هدف اصلی پست معرفی چنل بود، ولی به عنوان یه مطلب جانبی، در ادامه بحث مدیریت، به علاقه مندان پیشنهاد میکنم کتاب "مدیریت پروژه برای غیر مدیر پروژه" رو بخونن، عکس ترجمه فارسیش و پی دی اف زبان اصلیشم میزارم تو کامنت.

کارِ دستی؟ نه مرسی من برنامه نویسم! میخواستم لیست لینک های یه سری پادکست رو دانلود کنم (و تایتل و تاریخشون) با همین اسکریپت ساده لینک سیصد تا پادکست رو استخراج کردم. و یه کلیک راست و copy object و پیست کردنش توی یه فایل .json البته اسکرپر هایی که من نوشتم تو رنج های چند ده میلیون کار کردن 😎، ولی این لیست قراره فید یه پروژه خفن باشه که اون پروژه هنوز کامل نشده و بی صبرانه منتظرم تکمیل شه و پستش رو براتون بزارم. 🙌🏼 کدش توی کامنت.

میخواستم یه پکیجی رو دانلود کنم، بقیه پکیج هام با vpn اوکی شدن ولی این یکی اررور میداد، سرچ کردم و به اینجا رسیدم که تو عکس هست، رو اون لینکی که بالاش نوشته This question already has answers here کلیک کردم، رفتم سوال رو خوندم، بعد که رسیدم به کامنت هاش دیدم عه! اینو که آرشام آریا دو سال وخورده ای پیش پرسیده 😂 ولی همچنان جواب قابل قبولی براش نبود، این سری تجربم بیشتر بود، وی پی ان رو خاموش کردم و از goproxy.io به جاش استفاده کردم، و درست شد! جوابم هم تو استک آورفلو نوشتم که دوسال دیگه که دوباره این مشکل برام پیش اومد به داد خودم برسم 😂😂 لینک جواب (اگه به مشکل مشابه خوردید) https://stackoverflow.com/a/77336400/12972198

همیشه به دوستام میگم، همه ما آدما، حتی خفن ترین هامون، یه مجموعه بی انتها از ندانستن ها داریم، و یه محدوده خیلی خیلی کوچیک از دانایی. چیزی که کمک میکنه ارزش خلق کنیم و کارای بزرگ کنیم، روی هم گذاشتن همین دانش های کمه، قدرت همکاری، ارتباطات و کار تیمیه. مثل شبکه عصبی، مثل شبکه اینترنت، مثل قطعه های لگو، مثل شهری که هر خونه دو سه تا چراغ روشن کرده ولی وقتی از بالا بهش نگاه میکنی، روشنه و بینهایت جذاب. انسان یه موجود اجتماعیه، ما هستیم که با هم باشیم. ❤️✌️🏼 #فرهنگ #سافت_اسکیل #softskill

کمک به جامعه اپن سورس گاهی وقتا به همین سادگیه، از یه کتابخونه گولنگی برای نوشتن ربات تلگرام استفاده میکردم، برای هندل کردن کال بک ها یه نیازمندی داشتم و از طرفی هم حس میکردم فرآیند ساخت کیبوردش پیچیدست، تو پروژه های شخصی خودم این دوتا مشکل رو چند وقت پیش حل کرده بودم، دیروز به ذهنم رسید که از توی پروژه شخصیم به خود کتابخونه انتقالشون بدم، و همین چند دقیقه پیش مرج شد. کتابخونه اش اینه: https://github.com/yanzay/tbot زیاد معروف نیست (۳۴۰ ستاره) ولی راستش من از بقیه کتابخونه های گولنگی برای بات تلگرام بیشتر دوستش دارم.

#گولنگ #اررور_هندلینگ خیلی از پروژه های بزرگ از جمله #کوبرنتیز (kubernetes) یا influxDB، اررور هندلینگ رو مستقیما با fmt.Errorf میسازن، یه سری پروژه های بزرگ یا معروف دیگه، مثلا نتس (NATs)، میان از اررور های نامگذاری شده (NamedError) استفاده میکنن، یه پروژه هایی هم مثل کاکروچ (cockroachDB) میان از پکیج خودشون که البته "با اررور های خود گولنگ سازگاره" استفاده میکنن. حالا یه سری ویدئو هم تو یوتیوب هست و تو استارت آپ های ایرانی گاها خیلی بهش بها داده شده، که میان custom error تعریف میکنن و کلا تایپ دلخواه خودشون رو به عنوان اررور تو پروژه جا به جا میکنن. دوست دارم مزایا و معایب این روش ها از دیدگاه شما عزیزان رو بدونم، پست بعدی نظر سنجیه، خودمم نظرمم رو همونجا کامنت میکنم.

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