خوب سوباسا نداریم، چه کنیم؟ ۱۰ تا instance از ایشی زاکی بسازیم بکاریم کنار هم.
#چالش ساخت تصویر با AI
#چالش ساخت تصویر با AI
🤣9🤩1
چرا هر تیم نرمافزاری (حتی به ازای هر سرویس مجزا) باید Runbook داشته باشه ؟
تو دنیای امروز که سیستمها ۲۴/۷ کار میکنن، Runbook دیگه لوکس نیست، یه ضرورته.
این Runbook چیه؟سند زندهای که دقیقاً میگه:
🔘 سیستم چطوری کار میکنه؟
🔘 وقتی مشکلی پیش اومد چیکار کنیم؟ (Step-by-step)
🔘 وابستگیهای سیستم چیا هستن؟
🔘 چکلیستهای روزانه، هفتگی و ماهانه
🔘 راهحلهای رایج خطاها و Incidentها
🔘 اطلاعات تماس افراد کلیدی و Escalation Path
🔘 حتی به تیم های مرتبط میگه endpoint هامون چین و ورودی خروجی های مورد انتظارش چیه یا لینک به مستنداتی که این ها رو نشون بده.
اهمیت Runbook برای تیمهای نرمافزاری:
اثر 1- کاهش چشمگیر زمان Downtime
وقتی Incident اتفاق میافته، دیگه کسی سردرگم نیست که "اول کجا رو چک کنیم؟" تیم تو کمتر از ۵ دقیقه وارد Action میشه.
اثر 2- کاهش وابستگی به افراد خاص
- مثلا اگه یکی از اعضای کلیدی تیم مرخصی باشه یا شرکت رو ترک کنه، دانش از دست نمیره.
اثر 3- Onboarding خیلی سریعتر
- مثلا developer یا SRE جدید تو همون هفته اول میتونه Incidentهای سطح متوسط رو هندل کنه.
اثر 4- Consistency در عملیات
- همه اعضای تیم به یک روش استاندارد عمل میکنن، نه هر کسی به سلیقه خودش.
اثر 5- بهبود کیفیت و آرامش خاطر
- وقتی بدونید همه چیز مستند شده، خواب راحتتری دارید!
تجربه واقعی:
تیمهایی که Runbook خوب دارن، MTTR (Mean Time To Recovery) شون رو تا ۵۰-۷۰٪ کاهش دادن.
پیشنهاد من:
همین امروز یه Runbook اولیه برای مهمترین سرویسهاتون بسازید. حتی اگه ناقص باشه، بهتر از هیچی هست.
بعد به مرور کاملش کنید.از ابزارهایی مثل Notion، Confluence، Markdown تو GitHub یا GitLab Wiki میتونید استفاده کنید.
شما Runbook دارید؟
تو کامنت بگید تیمتون چقدر به مستندات عملیاتی اهمیت میده؟
#DevOps #SRE #Runbook #SiteReliability #SoftwareEngineering #تیم_فنی
تو دنیای امروز که سیستمها ۲۴/۷ کار میکنن، Runbook دیگه لوکس نیست، یه ضرورته.
این Runbook چیه؟سند زندهای که دقیقاً میگه:
🔘 سیستم چطوری کار میکنه؟
🔘 وقتی مشکلی پیش اومد چیکار کنیم؟ (Step-by-step)
🔘 وابستگیهای سیستم چیا هستن؟
🔘 چکلیستهای روزانه، هفتگی و ماهانه
🔘 راهحلهای رایج خطاها و Incidentها
🔘 اطلاعات تماس افراد کلیدی و Escalation Path
🔘 حتی به تیم های مرتبط میگه endpoint هامون چین و ورودی خروجی های مورد انتظارش چیه یا لینک به مستنداتی که این ها رو نشون بده.
اهمیت Runbook برای تیمهای نرمافزاری:
اثر 1- کاهش چشمگیر زمان Downtime
وقتی Incident اتفاق میافته، دیگه کسی سردرگم نیست که "اول کجا رو چک کنیم؟" تیم تو کمتر از ۵ دقیقه وارد Action میشه.
اثر 2- کاهش وابستگی به افراد خاص
- مثلا اگه یکی از اعضای کلیدی تیم مرخصی باشه یا شرکت رو ترک کنه، دانش از دست نمیره.
اثر 3- Onboarding خیلی سریعتر
- مثلا developer یا SRE جدید تو همون هفته اول میتونه Incidentهای سطح متوسط رو هندل کنه.
اثر 4- Consistency در عملیات
- همه اعضای تیم به یک روش استاندارد عمل میکنن، نه هر کسی به سلیقه خودش.
اثر 5- بهبود کیفیت و آرامش خاطر
- وقتی بدونید همه چیز مستند شده، خواب راحتتری دارید!
تجربه واقعی:
تیمهایی که Runbook خوب دارن، MTTR (Mean Time To Recovery) شون رو تا ۵۰-۷۰٪ کاهش دادن.
پیشنهاد من:
همین امروز یه Runbook اولیه برای مهمترین سرویسهاتون بسازید. حتی اگه ناقص باشه، بهتر از هیچی هست.
بعد به مرور کاملش کنید.از ابزارهایی مثل Notion، Confluence، Markdown تو GitHub یا GitLab Wiki میتونید استفاده کنید.
شما Runbook دارید؟
تو کامنت بگید تیمتون چقدر به مستندات عملیاتی اهمیت میده؟
#DevOps #SRE #Runbook #SiteReliability #SoftwareEngineering #تیم_فنی
❤13👍2
مسعود بیگی
چرا هر تیم نرمافزاری (حتی به ازای هر سرویس مجزا) باید Runbook داشته باشه ؟ تو دنیای امروز که سیستمها ۲۴/۷ کار میکنن، Runbook دیگه لوکس نیست، یه ضرورته. این Runbook چیه؟سند زندهای که دقیقاً میگه: 🔘 سیستم چطوری کار میکنه؟ 🔘 وقتی مشکلی پیش اومد چیکار کنیم؟…
مقاله بسیار مفید برای کشف این اثر :
https://incident.io/blog/automated-runbook-guide
تعریف شاخص MTTR و دستهبندی تیمها بر اساس متدولوژی گوگل (DORA) (مستنداتی که دستهبندی مراجع گوگل برای سنجش تفاوت تیمهای Elite، High و Medium را در حل بحرانها نشان میدهد)
https://agileanalytics.cloud/docs/mttr
https://incident.io/blog/automated-runbook-guide
تعریف شاخص MTTR و دستهبندی تیمها بر اساس متدولوژی گوگل (DORA) (مستنداتی که دستهبندی مراجع گوگل برای سنجش تفاوت تیمهای Elite، High و Medium را در حل بحرانها نشان میدهد)
https://agileanalytics.cloud/docs/mttr
incident.io
How to build automated runbooks that reduce MTTR by 50% | Blog
Automated runbooks reduce MTTR by 30-50% by replacing static docs with executable workflows that trigger diagnostics and remediation.
👍5❤1
حس میکنم این روزها stakeholder management م به صورت چشمگیری پیشرفت داشته 😎
🔥6👏1
همین حالا تو کامنت های کانال های ارزشمند میبینم که دولوپر ها وقت بیشتری برای فلسفی فکر کردن به مسائل دارند.. و این از مزایای موج ابزارهای خوب و زیاد ai ی هست که اومده.
👏4🔥1
Forwarded from ..: لیکفا | Leakfa :..
🚨 نقض جدید: اطلاعات میلیونها مسافر و مشتری آژانسهای خدمات گردشگری در معرض افشا
🔍 مجموعه بزرگی حاوی بیش از 2 ترابایت از اطلاعات شرکت «فرانگر پارس سیستم» که ظاهرا چندی پیش مورد نفوذ قرار گرفته بود، در فهرست فروشندگان بانکهای اطلاعاتی غیرمجاز مشاهده شده است. این مجموعه شامل فایلهای داخلی، سورسکدها و اطلاعات هویتی، شماره تماس، ایمیل، شماره ملی، شماره پاسپورت، جزئیات سفر، رزرو و پرداخت و اطلاعات دیگری مربوط به خدمات هواپیما، قطار، اتوبوس، هتل و اقامتگاه شرکتهای هفت اورنگ، تیک بان، هیلداسیر، رهبال آسمان، کارمانیا، اسنپ تریپ، آوان گشت، به پرواز تبریز، سپهر جم، تعطیلات، پیک خورشید، سفر ایران، علاالدین تراول، فاروس تور، نیوار پرواز ایرانیان، آسمان سپید، ساینا سیر، کاروان هوایی، آسمان پرواز و سفرهای علی فلک است.
📌 افشای این اطلاعات میتواند زمینهساز حملات فیشینگ هدفمند، کلاهبرداری، سوءاستفاده از اطلاعات هویتی و رهگیری برنامههای سفر افراد شود. کاربران باید نسبت به پیامها، تماسها و درخواستهای مشکوک هوشیار باشند.
✅ صحت دادههای ارائهشده در بررسی نمونهای تایید شد.
🆔 @leakfarsi
🔍 مجموعه بزرگی حاوی بیش از 2 ترابایت از اطلاعات شرکت «فرانگر پارس سیستم» که ظاهرا چندی پیش مورد نفوذ قرار گرفته بود، در فهرست فروشندگان بانکهای اطلاعاتی غیرمجاز مشاهده شده است. این مجموعه شامل فایلهای داخلی، سورسکدها و اطلاعات هویتی، شماره تماس، ایمیل، شماره ملی، شماره پاسپورت، جزئیات سفر، رزرو و پرداخت و اطلاعات دیگری مربوط به خدمات هواپیما، قطار، اتوبوس، هتل و اقامتگاه شرکتهای هفت اورنگ، تیک بان، هیلداسیر، رهبال آسمان، کارمانیا، اسنپ تریپ، آوان گشت، به پرواز تبریز، سپهر جم، تعطیلات، پیک خورشید، سفر ایران، علاالدین تراول، فاروس تور، نیوار پرواز ایرانیان، آسمان سپید، ساینا سیر، کاروان هوایی، آسمان پرواز و سفرهای علی فلک است.
📌 افشای این اطلاعات میتواند زمینهساز حملات فیشینگ هدفمند، کلاهبرداری، سوءاستفاده از اطلاعات هویتی و رهگیری برنامههای سفر افراد شود. کاربران باید نسبت به پیامها، تماسها و درخواستهای مشکوک هوشیار باشند.
✅ صحت دادههای ارائهشده در بررسی نمونهای تایید شد.
🆔 @leakfarsi
از لحظه ای که تصمیم بگیریم که به ارزش های واقعی خودمون واقف بشیم و روشون تمرکز کنیم، تا لحظه ای که این ارزش ها برای ما خلق ثروت کنند، خیلی مسیر کوتاه تری داریم نسبت به سایر مسیرها.
👍17❤6👎3
اگه محتوای ارزشمندی روی سرویس تون دارین و میخواین کار کرالر هاو اسکرپر ها رو سخت تر کنید، حتما توی جستجوتون محدودیت تعداد کاراکتر بذارین، مثلا زیر ۳ کاراکتر سرچ انجام نشه. فقط اینو عاقلانه توی بکند یا BFF بذارین نه توی فرانت 😁😎😈
🤣6💔1
Forwarded from Learning With M
#عجیب_دنیایی_شد
فورد بعد از اینکه نیروهاش رو با هوش مصنوعی جایگزین کرده بود، ۳۵۰ تا مهندس رو دوباره استخدام کرد.
معاون مهندسی فورد گفته که شرکت اشتباه فکر می کرد هوش مصنوعی بهتنهایی می تونه جای مهندس های باتجربه رو بگیره و همچنان ماشین های با کیفیت تولید کنه.
اما نتیجه برعکس شد؛ بعد از اینکه از سال ۲۰۲۰ بیش از ۵۰۰۰ نفر رو تعدیل کرد، امسال فورد بیشتر از هر خودروساز دیگه ای در آمریکا مجبور شده خودرو هاش رو فراخوان کنه.
جالبه که مدیرعامل فورد، Jim Farley، قبلاً گفته بود:
«هوش مصنوعی قراره واقعاً جای نیمی از کارمند های دفتری (white-collar) رو بگیره.»
نکشیمون پیشگوی بزرگ
فورد بعد از اینکه نیروهاش رو با هوش مصنوعی جایگزین کرده بود، ۳۵۰ تا مهندس رو دوباره استخدام کرد.
معاون مهندسی فورد گفته که شرکت اشتباه فکر می کرد هوش مصنوعی بهتنهایی می تونه جای مهندس های باتجربه رو بگیره و همچنان ماشین های با کیفیت تولید کنه.
اما نتیجه برعکس شد؛ بعد از اینکه از سال ۲۰۲۰ بیش از ۵۰۰۰ نفر رو تعدیل کرد، امسال فورد بیشتر از هر خودروساز دیگه ای در آمریکا مجبور شده خودرو هاش رو فراخوان کنه.
جالبه که مدیرعامل فورد، Jim Farley، قبلاً گفته بود:
«هوش مصنوعی قراره واقعاً جای نیمی از کارمند های دفتری (white-collar) رو بگیره.»
نکشیمون پیشگوی بزرگ
👍11🤣4
Forwarded from tech-afternoon (Amin Mesbahi)
نقش Forward Deployed Engineer یا FDE
توصیف ساده FDE کسیه که برای تولید محصول، به جای منتظرِ requirement موندن، خودش میره وسط میدون، requirement رو کشف میکنه، ابهامها رو کم میکنه، prototype یا راهحل production-ready میسازه، سیستم رو با محیط واقعی customer fit میکنه و فیدبکها رو برمیگردونه به محصول.
کِی FDE کاربرد داره؟
ریشه پیدایش چنین نقشی بیشتر به شرکتهایی مثل Palantir برمیگرده.
وقتی محصول خیلی تکنیکال باشه، در عین حال، مشتری که میتونه کاربر درونسازمانی هم باشه؛ خیلی technical نیست. مثلا شرکت Palantir، محصولاتی مثل پلتفرمهای AI/Agentic، یا ابزارهای پیچیده انترپرایز که توی صنایع سنتی مثل manufacturing، aviation، CPG و HR استفاده میشن داره. یعنی جایی که مشتری، مسئله بزرگ یا خیلی بزرگ داره، ولی توان فنی کافی برای تبدیل مسئله به راهحل نرمافزاری نداره.
دقت کنیم که FDE به هیچ وجه Sales Engineer یا Software Engineer معمولی یا Consultant / Professional Services نیست!
بهطور خلاصه، FDE یک مهندس مشتریمحوره که بین consulting، product management و software engineering میایسته، ولی خروجی نهاییش باید نرمافزار و outcome واقعی برای مشتری باشه، نه فقط دمو، تحلیل یا توصیه.
فرق بین ownership of project و ownership of problem اینجا خیلی مهمه. آدمی که project ownership دارد ممکنه آدم سختکوشی باشه، ساعات زیادی کار کنه و پروژه رو هم تموم کنه. ولی FDE باید problem ownership داشته باشه. یعنی موفقیتش با این سنجیده میشه که آیا مشکل مشتری واقعاً حل شده یا نه، نه اینکه PR merge شده یا ticket بسته شده.
چنین افرادی برای سازمانها خیلی ارزشمندن. چه برای مصاحبه کردن چه در ارزیابی خودتون میتونید از ۳ بُعد بررسی کنید که به صورت کلیدواژه و خلاصه میگم:
بُعد Communication -> شنیدن فعال، شفاف حرف زدن، آماده بودن و executive presence
بُعد Product sense -> توضیح تصمیمها، انتخاب scope درست و trade-off prioritization
بُعد Engineering -> درک عمیق از completeness، test cases، edge cases misuse cases، end-to-end delivery
نکته مهم هم اینه که FDE برای همهجا مناسب نیست. برای محیطهای پویا و خلاق و پیشرفته؛ ارزش زیادی داره، چون فرد میتونه کنار تیم بیزینس یا عملیات بنشینه و سریع adjustment رو انجام بده. اما توی سیستمهای سنتی، stable، heavily governed و با release process سختگیرانه، این مدل اگه درست کنترل نشه میتونه ریسک تولید کنه.
این هم فراموش نکنیم که عنوانهای جدید، همیشه با خودشون جوگیری رو هم میارن؛ خصوصا این روزها و با وجود AI!
توصیف ساده FDE کسیه که برای تولید محصول، به جای منتظرِ requirement موندن، خودش میره وسط میدون، requirement رو کشف میکنه، ابهامها رو کم میکنه، prototype یا راهحل production-ready میسازه، سیستم رو با محیط واقعی customer fit میکنه و فیدبکها رو برمیگردونه به محصول.
کِی FDE کاربرد داره؟
ریشه پیدایش چنین نقشی بیشتر به شرکتهایی مثل Palantir برمیگرده.
وقتی محصول خیلی تکنیکال باشه، در عین حال، مشتری که میتونه کاربر درونسازمانی هم باشه؛ خیلی technical نیست. مثلا شرکت Palantir، محصولاتی مثل پلتفرمهای AI/Agentic، یا ابزارهای پیچیده انترپرایز که توی صنایع سنتی مثل manufacturing، aviation، CPG و HR استفاده میشن داره. یعنی جایی که مشتری، مسئله بزرگ یا خیلی بزرگ داره، ولی توان فنی کافی برای تبدیل مسئله به راهحل نرمافزاری نداره.
دقت کنیم که FDE به هیچ وجه Sales Engineer یا Software Engineer معمولی یا Consultant / Professional Services نیست!
بهطور خلاصه، FDE یک مهندس مشتریمحوره که بین consulting، product management و software engineering میایسته، ولی خروجی نهاییش باید نرمافزار و outcome واقعی برای مشتری باشه، نه فقط دمو، تحلیل یا توصیه.
فرق بین ownership of project و ownership of problem اینجا خیلی مهمه. آدمی که project ownership دارد ممکنه آدم سختکوشی باشه، ساعات زیادی کار کنه و پروژه رو هم تموم کنه. ولی FDE باید problem ownership داشته باشه. یعنی موفقیتش با این سنجیده میشه که آیا مشکل مشتری واقعاً حل شده یا نه، نه اینکه PR merge شده یا ticket بسته شده.
چنین افرادی برای سازمانها خیلی ارزشمندن. چه برای مصاحبه کردن چه در ارزیابی خودتون میتونید از ۳ بُعد بررسی کنید که به صورت کلیدواژه و خلاصه میگم:
بُعد Communication -> شنیدن فعال، شفاف حرف زدن، آماده بودن و executive presence
بُعد Product sense -> توضیح تصمیمها، انتخاب scope درست و trade-off prioritization
بُعد Engineering -> درک عمیق از completeness، test cases، edge cases misuse cases، end-to-end delivery
نکته مهم هم اینه که FDE برای همهجا مناسب نیست. برای محیطهای پویا و خلاق و پیشرفته؛ ارزش زیادی داره، چون فرد میتونه کنار تیم بیزینس یا عملیات بنشینه و سریع adjustment رو انجام بده. اما توی سیستمهای سنتی، stable، heavily governed و با release process سختگیرانه، این مدل اگه درست کنترل نشه میتونه ریسک تولید کنه.
این هم فراموش نکنیم که عنوانهای جدید، همیشه با خودشون جوگیری رو هم میارن؛ خصوصا این روزها و با وجود AI!
❤3
Media is too big
VIEW IN TELEGRAM
بعد ۲۰ سال اومدم جایی که هنرستان رفته بودم کارآموزی، دنیا همینقدر گرده ها..
❤14
Forwarded from KMS HUB (MohammadReza)
✨رویداد تخصصی
🎯 هوش مصنوعی در پروداکشن
در این رویداد میزبان مهندس مسعود بیگی خواهیم بود؛ فعال باسابقه حوزه مهندسی نرمافزار، مدرس، منتور و رهبر تیمهای فنی که سابقه فعالیت بهعنوان
⭐️CTO ،
⭐️ Technical Facilitator ،
⭐️ Co-Founder
در شرکتهای مختلف را در کارنامه خود دارد.
در این نشست، تجربههای واقعی استفاده از هوش مصنوعی در محصولات، چالشهای استقرار AI در محیط Production، تصمیمهای معماری و درسهایی که از توسعه سیستمهای واقعی به دست آمده را با هم مرور خواهیم کرد.
🌟 شرکت در رویداد رایگان است؛ ظرفیت پذیرش محدود است.
🪑 جهت شرکت در رویداد، به آیدی زیر پیام دهید:
💬 : @Xx_LORD_xX
🔖 وبسایت: kmshub.ir
💡گروه تلگرام: @KmsHub
💬اینستاگرام: KmsHubir
📣 کانال تلگرام: @KmsHubir
⚡️ لینکدین : LinkedIn
🎯 هوش مصنوعی در پروداکشن
در این رویداد میزبان مهندس مسعود بیگی خواهیم بود؛ فعال باسابقه حوزه مهندسی نرمافزار، مدرس، منتور و رهبر تیمهای فنی که سابقه فعالیت بهعنوان
⭐️CTO ،
⭐️ Technical Facilitator ،
⭐️ Co-Founder
در شرکتهای مختلف را در کارنامه خود دارد.
در این نشست، تجربههای واقعی استفاده از هوش مصنوعی در محصولات، چالشهای استقرار AI در محیط Production، تصمیمهای معماری و درسهایی که از توسعه سیستمهای واقعی به دست آمده را با هم مرور خواهیم کرد.
🗓 دوشنبه ۱۵ تیرماه | ⏰ ساعت ۱۷:۰۰
📌 محل برگزاری: از طریق کانال کرمانشاه هاب اطلاعرسانی خواهد شد.
🌟 شرکت در رویداد رایگان است؛ ظرفیت پذیرش محدود است.
🪑 جهت شرکت در رویداد، به آیدی زیر پیام دهید:
💬 : @Xx_LORD_xX
🔖 وبسایت: kmshub.ir
💡گروه تلگرام: @KmsHub
💬اینستاگرام: KmsHubir
📣 کانال تلگرام: @KmsHubir
⚡️ لینکدین : LinkedIn
❤3🔥2
Forwarded from جادی | Jadi
نمودار مومنتوم که در فوتبالها نشون میدن چیه؟
این نمودار «مومنتوم» که اخیرا زیر مسابقات نشون می دن یه ایده دیتایی است. چیزی شبیه به پیش بینی هوا. این نمودار داره می گه در هر لحظه احتمال گل زدن هر تیم چقدره و این رو بر اساس تحلیل داده و یادگیری ماشین روی بازی های قبلی اون ورزش به دست میاره. این نمودار منطقا بسیار بهتر به ما «وضعیت» بازی رو نشون می ده و باعث میشه بیشتر از «مالکیت» یا «تعداد شوت» بفهمیم بازی چطوری بوده و چطوری داره پیش می ره.
این نمودار در واقع بر اساس یادگیری ماشین و بر اساس فاکتورهایی مثل طول مالکیت توپ، مکان زمین، جهت حرکت، تعداد بازیکنان هر تیم در اطراف توپ، تعداد پاس سالم منتبج به وضعیت فعلی و ... پیش یبنی می کنه که در این لحظه چقدر احتمال داره توپ گل بشه.
https://youtu.be/Oe-B2UciDC0
این نمودار «مومنتوم» که اخیرا زیر مسابقات نشون می دن یه ایده دیتایی است. چیزی شبیه به پیش بینی هوا. این نمودار داره می گه در هر لحظه احتمال گل زدن هر تیم چقدره و این رو بر اساس تحلیل داده و یادگیری ماشین روی بازی های قبلی اون ورزش به دست میاره. این نمودار منطقا بسیار بهتر به ما «وضعیت» بازی رو نشون می ده و باعث میشه بیشتر از «مالکیت» یا «تعداد شوت» بفهمیم بازی چطوری بوده و چطوری داره پیش می ره.
این نمودار در واقع بر اساس یادگیری ماشین و بر اساس فاکتورهایی مثل طول مالکیت توپ، مکان زمین، جهت حرکت، تعداد بازیکنان هر تیم در اطراف توپ، تعداد پاس سالم منتبج به وضعیت فعلی و ... پیش یبنی می کنه که در این لحظه چقدر احتمال داره توپ گل بشه.
https://youtu.be/Oe-B2UciDC0
YouTube
نمودار مومنتوم فوتبال دقیقا چیه
این نمودار «مومنتوم» که اخیرا زیر مسابقات نشون می دن یه ایده دیتایی است. چیزی شبیه به پیش بینی هوا. این نمودار داره می گه در هر لحظه احتمال گل زدن هر تیم چقدره و این رو بر اساس تحلیل داده و یادگیری ماشین روی بازی های قبلی اون ورزش به دست میاره. این نمودار…
❤6
This media is not supported in your browser
VIEW IN TELEGRAM
عالی شد، از این به بعد پروفایل منتورهای #Adplist میتونه با استفاده از ابزارهاش به کلاودی وصل بشه و ملت ماها رو اونجا پیدا کنن :)
من همینجوریش تلاش میکنم منتورینگ رو کم و کم تر کنم چون از یه سری فاکتورهای سمت خودم اصلا راضی نیستم. اینجوری احتمالا باید کلا برم پروفایلم رو پاک کنم.
من همینجوریش تلاش میکنم منتورینگ رو کم و کم تر کنم چون از یه سری فاکتورهای سمت خودم اصلا راضی نیستم. اینجوری احتمالا باید کلا برم پروفایلم رو پاک کنم.
❤6👎1