رفقا شب مهندس مبارک! 🥳
ببخشید دیر شد سرم تو کد بود متوجه گذر عمر نشدم 😂

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

زیاد میشنوم که میگن تست به دیباگ کردن کد کمک میکنه، اما این ممکنه یکم گمراه کننده باشه.

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

ولی خب، تو یه سری مدل تست ها مثل e2e و load test هم مجددا سناریو رو میدونیم، با اینحال ممکنه قسمتی از فلو (flow)، مطابق انتظار پیش نره، لود تست که کلا داستان خاص خودشو داره،
ولی تو e2e هم مجددا اگه ایراد پیش‌بینی نشده ای پیدا بشه، احتمالا در نقاط اتصال هست، و e2e هم تو پیدا کردن باگ لاجیکی غیرمنتظره، کمکی به ما نمیکنه.

<--×-->

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

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

<--×-->

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

غیر منطقی به نظر میاد،
اما منم بارها شاهدش بودم!
ولی مسئله اینجا تست نیست،
باید به خیلی قبل ترش نگاه کنیم،
همون جایی که نیازمندی بیزنس داره مشخص میشه.

<--×-->

از خوبی های جانبی تست هم میشه به "مثال بودن" اش اشاره کرد. با فرض دنیای ایده آل، خوندن تست های یه پروژه خیلی ساده تر از خوندن کد خود پروژست، و از رو تست هاش میشه به سادگی فهمید که چیکار میکنه و ورودی و خروجی مورد انتظار سیستم چی هست.
البته خب تو دنیای واقعی و غیر ایده آل، ممکنه یه دولوپر تازه کار مدعی سینیوریتی همین تست هارو فراپیچیده (over complex) کنه.

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

<--×-->

ولی خب در کل نظر شما راجع به تست چیه؟
مزایا؟ معایب؟ پیشنهاد؟ انتقاد؟ به من، به پست، به کانال و... 🙂🙌🏼

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

چشامو بستم و باز کردم، دیدم دو ساله که تو اسنپم...
<<--×-->>
بعد از بیرون اومدن از شرکت قبلی،
به تنها چیزی که فکر میکردم مهاجرت بود،
اون موقع با حمایت شما کانکشن های عزیزم شرکتای زیادی بهم پیام دادن، ولی خب چون هدفم مهاجرت بود، همه ایرانی هاش رو ریجکت کردم... به جز اسنپ.

اسنپ که بهم پیام داد، خب بالاخره اسنپ بود! خفن ترین شرکت تکنولوژی ایران رو مگه میشه رد کرد؟ چی از این بهتر که بتونی رو زندگی چند میلیون نفر تاثیر مثبت بزاری...
<<--×-->>
وارد پروسه شدم،
و اتفاقا به خاطر وضعیت اون موقع (اعتراضات) حال روحی اصلا خوبی نداشتم و مصاحبه اولم هم خوب پیش نرفت.
ولی مصاحبه دومم که با نیما قائدشرفی عزیز بود، خیلی خوب پیش رفت و تونستم خودمو نشون بدم، تو همون یه ساعت کلی چیز یاد گرفتم.

سه تا نکتشو یادمه:
اول که خیلی خودمونی شروع کرد و یخ من آدم خجالتی رو شکوند،

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

و سوم رو توضیحات من راجع به پروژه هام خیلی فلسفی شد، جوری که من مطالعه راجع به "هنر پرسشگری و تفکر نقادانه" رو تو برنامه هام گذاشتم و همینم خیلی تو مسیر شغلیم کمکم کرد.
<<--×-->>
نهایتا موفق شدم و وارد شدم،
خیلی خوشحالم که این اتفاق برام افتاد،
کسایی که از نزدیک یا از پست هام منو میشناسن میدونن که چقدر تو زندگیم تلاش کردم، له شدم، مچاله شدم، اما هیچوقت تسلیم نشدم، تا نهایتا به نقطه ای رسیدم که میگم "آها، این همون نقطه شروعیه که لایقش بودم".

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

از چیزای خوبی که تو اسنپ دیدم باید پست های زیادی بزارم که بقیه سازمان ها یاد بگیرن، یاد بگیرن که "توجه به نیرو ها، هزینه نیست، سرمایه گذاریه!"، دقیقا کاری که اسنپ میکنه و رشدش رو هم مدیون همینه.

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

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

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

<--×-->

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

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

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

<--×-->

راه حل؟
- به توانایی نوشتن و انتقال دانش، به چشم یه مهارت ضروری نگاه کنیم، نه یه مهارتی که هعییی، میتونه امتیاز باشه!
این باعث میشه نیرو هامون به سمت یاد گرفتن "انتقال دانش" برن و مشتاق باشن انجامش بدن و نه تنها سازمان بهره ببره، بلکه نیرو تو کل مسیر شغلی اش از داشتن این مهارت لذت ببره! و حتی این کالچر رو به سازمان های بعدی اش هم منتقل کنه.

- به عنوان سازمان، ظرفیت کافی برای انتقال دانش در نظر بگیریم، مثل تیز کردن اره میمونه.

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

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

نظر شما چیه؟

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

? در این سری جلسات کتاب Designing Data-Intensive Applications (THE BIG IDEAS BEHIND RELIABLE, SCALABLE, AND MAINTAINABLE SYSTEMS) از نشر o'reilly را بررسی خواهیم کرد. آرشام در این پست بیشتر در مورد این کتاب توضیح داده.

? در جلسات قصد هست همانطور که کتاب هم تاکید داره تبیین درستی از کلمه Data در حوزه #توسعه #نرم_افزار برای خودمون ایجاد کنیم. هر چند همین ابتدا تاکید می کنیم، این کلمه Data محدود به حوزه توسعه نرم افزار قطعا نیست.

✨در انتها یک جلمه از هم پیش گفتار کتاب اینجا بیاریم و یادآوری کنیم که یکی از اهداف از سلسه جلسات قبل یعنی بررسی #فلسفه_علم دقیقا فهم چرایی جمله زیر هست که در اونجا با #یادگیری و جداسازی #علم از #ابزار می تونیم با درک عمیق پرسش ها، #تصمیم_سازی های با کیفیت تری داشته باشه.
Software keeps changing, but the fundamental principles remain the same.

کتاب آوردم براتون قویییی ?✌️??
کتابی که میخوام معرفی کنم رو خودم حدود ۷۰ درصدشو خوندم، بقیشم دارم میخونم (همزمان البته با چند کتاب دیگه) و سنگین هم هست و بنابراین کند پیش میرم یکم.

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

کتاب Designing data-intensive applications نوشته آقای مارتین کلپمن (که ایشون استاد دانشگاه کمبریج هستن و از مهندس های ارشد لینکداین بودن) کتابیه که تمرکزش روی طراحی بهینه نرم افزار هاییه که مسئولیت نگهداری و جا به جایی اطلاعات رو دارن (نرم افزار های statefull، دیتابیس ها، بروکر ها و...)

مخاطب های زیادی میتونه داشته باشه، ولی برای backed engineer ها، data engineer ها، منیجر های تیم های فنی به شدت پیشنهاد میشه. (خودشم مثل اکثر کتابای خوب، تو صفحات اولش کامل توضیح داده برا چه افرادی مناسبه)

کتاب از سه بخش (part) اصلی تشکیل شده:
- foundation of data systems
- distributed data (replication, partitioning, etc.)
- derived data (streaming and batch processing)

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

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

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

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

پارت سوم هم راجع به derived data (اطلاعات مشتق شده) هست و فصل هایی مثل batch processing و stream processing رو شامل میشه که به ترتیب بهشون offline و near real-time هم میگن.
این دسته از اطلاعات میشه گفت دیتای دسته اول یا source of truth ما نیستن و ما برای یوزکیس های زیادی که مطرح میشه میسازیمشون (مثلا analytics).
فصل اولش (۱۰ ام کتاب) با یه مثال از فلسفه یونیکس شروع میشه و به طور جذابی با همین مثال کوچیک میره جلو و distribute میکنه و...

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

#کتاب #معرفی_کتاب

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

یا مثلا یه چیزی رو ندونید، اما ندونید چی باید سرچ کنید که یادش بگیرید؟ مثلا تو مکالمه همکارات بشنوی "p99 اش چنده؟" قبلنا که یادمه گوگل نتایج قابل قبولی برای این نمیداد، ولی ساده است، میگمش بعدا. (کلیت سوالم رو دریابید فارق از مثال)

یه حالت بدتر هم وجود داره، که مشکل خوردن، اما اصلا نمیدونن مشکل خوردن! (مثلا چندتا گوروتین اون گوشه نشستن نون و پنیرشونو میخورن به کسی هم کار ندارن (dangling goroutines))

یا میدونن مشکل خوردن اما بهش بی توجهی میکنن مثلا سرور هفته ای یه بار کرش میکنه، ری استارت میکنن و درست میشه و روز از نو روزی از نو! Availability هم که... کشک! ?

قسمت سختش وقتیه که میخواید یه سیستم جدید دیزاین کنید،
- نمیدونید از کجا شروع کنید
- نمیدونید چه تصمیمی درست یا غلط، چون پارامتر های مقایسه اش رو نمیدونید
- یا جوانب مختلفش رو بدونید که هست اما نتونید ببینید

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

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

یا تو همین موقعیتی که هستم نواقصی رو خواهم دید که قبلا نمیدیدم (مطمئنم این اتفاقا میوفته چون چندین بار تجربش کردم)

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

داستان یه پروژه شخصی (پادکرایب)
من پروژه های شخصی زیادی دارم،
بعضیاشو دارم همچنان پیش میرم،
بعضیاشو رها کردم،
بعضیاشم هنوز شروع نکردم،
خلاصه مثل خیلی دیگه از برنامه نویسا ??

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

خواستم متن پادکست هارو پیدا کنم، چیزی پیدا نشد،
یه سری ابزار هم برای ویس به متن بودن که همه پولی و پرداخت دلاری،
تا اینکه با پروژه ویسپر آشنا شدم،
اول از همه فلو رو دستی اجرا کردم،
ویسپر mp3 ساپورت نمیکرد و باید wav بهش میدادم،
پس فلو میشه این:
- کراول پادکست
- دانلودش به صورت کانکارنت
- تبدیلش به کمک ffmpeg
- بیلد و ست آپ ویسپر لوکال
- تبدیل ویس به متن

حالا نوبت چسبوندن این قطعات به هم بود،
- یه فایل باینری ffmpeg که کار تبدیل (mp3->wav) رو انجام میده،
- پروژه ویسپر که به زبان C نوشته شده و ست آپ خاص داره،
- یه سری کد گولنگی برای مدیریت برنامه و مدیریت دانلود

دوست عزیزم محمد جهانی اینجا کمکم کرد بهم گفت که اینجور پروژه ها معمولا یه چیزی دارن به اسم bindings (کلمه جدیدی بود برام)
و بایندینگ های ویسپر و ffmpeg رو پیدا کردیم (اتفاقا رو بایندینگ ffmpeg بعدا که کانتریبیوت هم زدم)

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

منتها بایندینگ های ویسپر خیلی مشکل داشت،
به این شکل که باید خود ویسپر رو کلون میکردیم،
و go get اش هم باید میکردیم،
و اینا version mismatch میخوردن گاهی الکی،
و باید یه ریپلیس هم تو گو مود میزدیم.

و از یه جایی به بعد هم، ایمیج ما رو پایپ لاین بیلد میشد اما دیگه روی لپتاپ من بیلد نمیشد (به خاطر ناسازگاری Apple M1)

یه ایشو باز کردم رو ویسپر و آقای josharian از خفنای اپن سورس گولنگ، با نیم خط کامنت فیکسش کرد ?

هیچی خوب پیش نمیرفت تا اینکه گوگل اومد اعلامیه داد گوگل پادکست رو میخواد با گوگل موزیک مرج کنه ?
ما کست باکس هم داشتیم،
کراول اپل پادکست رو البته گذاشته بودیم برا بعدا،
ولی خب بعد این خبر رفتیم رو هوا ?

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

اما من تسلیم میشم؟
نه پیوت میکنم ?

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

خب الان چه کنیم؟
بکوبیم از نو بسازیم پروژه رو،
یه قسمتایی از پرداخت کریپتویی رو زدم،
و با OpenAI API هم ارتباط گرفتم،
چندتا کانتریبیوت هم این وسط زدم،
بعد تلگرام stars اومد ?

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

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

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

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