چیزهایی که خوبه یاد داشته باشیم اگه دنبال قدم بعدی در دنیا بکاند میگردید:
1. داکر ( دیگه باید همه بلد باشن :) )
2. لینوکس ( اگه بکاند کارید قطعا! )
3. ردیس ( اینم مثل داکر )
4. ربیت امکیو ( ردیس همین کار رو هم میکنه ولی اینو خیلی جاها میخان)
5. الستیکسرچ ( پست بالا )
6. میکروسرویس( تو لول ها بالاتر، و کلا distributed systems )
7. خود SQL (میتونه خیلی کمک کنه در آینده بهتون)
8. پستگرس اسکیول ( دیتابیس رایج خیلیهاست)
9. دیزاین پترن ( به عنوان یک دولوپر دونستاش خیلی کمک میکنه. البته تو ایران خیلیها میپرسن تو مصاحبه)
10. کوبرنتیز :)
در کنار اینا قطعا داشتن یک درک خوب از خود HTTP مهمه و خیلی چیزای دیگه که در این لحظه یادم نمیاد. از این لیست خیلیهاشو خود منم هنوز یاد ندارم، ولی یاد خواهم گرفت؟ قطعا.
بعدا برای همه اینایی که تو لیست گفتم دوره آموزش مناسب میزارم. احتمالا پست بعدی بشه این :)
👾 @TorhamDevCH
1. داکر ( دیگه باید همه بلد باشن :) )
2. لینوکس ( اگه بکاند کارید قطعا! )
3. ردیس ( اینم مثل داکر )
4. ربیت امکیو ( ردیس همین کار رو هم میکنه ولی اینو خیلی جاها میخان)
5. الستیکسرچ ( پست بالا )
6. میکروسرویس( تو لول ها بالاتر، و کلا distributed systems )
7. خود SQL (میتونه خیلی کمک کنه در آینده بهتون)
8. پستگرس اسکیول ( دیتابیس رایج خیلیهاست)
9. دیزاین پترن ( به عنوان یک دولوپر دونستاش خیلی کمک میکنه. البته تو ایران خیلیها میپرسن تو مصاحبه)
10. کوبرنتیز :)
در کنار اینا قطعا داشتن یک درک خوب از خود HTTP مهمه و خیلی چیزای دیگه که در این لحظه یادم نمیاد. از این لیست خیلیهاشو خود منم هنوز یاد ندارم، ولی یاد خواهم گرفت؟ قطعا.
بعدا برای همه اینایی که تو لیست گفتم دوره آموزش مناسب میزارم. احتمالا پست بعدی بشه این :)
👾 @TorhamDevCH
👍14❤1
TorhamDev | تورهام 😳
چیزهایی که خوبه یاد داشته باشیم اگه دنبال قدم بعدی در دنیا بکاند میگردید: 1. داکر ( دیگه باید همه بلد باشن :) ) 2. لینوکس ( اگه بکاند کارید قطعا! ) 3. ردیس ( اینم مثل داکر ) 4. ربیت امکیو ( ردیس همین کار رو هم میکنه ولی اینو خیلی جاها میخان) 5. الستیکسرچ…
نظر مانی هم خوب بود :)
rabbitmq همون کاره ردیسو نمیکنه ها. خیلی تفاوت داره یوزکیسشون.
الستیک بنظرم واقعا الزامی نیست بلد بودنش. خیلی جاها دیدم استفاده نمیکنن.
دونستن دیزاین پترن خوبه. ولی از نظر اهمیت شاید اخره این لیست باشه.
دونستن لینوکس هم خوبه ولی در حد بلد بودن کامنداش. بیشترش ممکنه به دردتون نخوره با توجه به اینکه اکثرا دیگه کلاد هستن.
۱۱. کلاد و AWS
۱۲. تست نویسی
۱۳. مانیتورینگ و instrument و telemetry خیلی مهم تره.
۱۴. architecture design (خیلی مهم تره تا دیزاین پترن)
https://roadmap.sh/backend
کلا نمیدونم مشکل همه چیه با این رودمپ... خیلی کامل و دقیق گفته. فقط کلاد توش جا مونده.
rabbitmq همون کاره ردیسو نمیکنه ها. خیلی تفاوت داره یوزکیسشون.
الستیک بنظرم واقعا الزامی نیست بلد بودنش. خیلی جاها دیدم استفاده نمیکنن.
دونستن دیزاین پترن خوبه. ولی از نظر اهمیت شاید اخره این لیست باشه.
دونستن لینوکس هم خوبه ولی در حد بلد بودن کامنداش. بیشترش ممکنه به دردتون نخوره با توجه به اینکه اکثرا دیگه کلاد هستن.
۱۱. کلاد و AWS
۱۲. تست نویسی
۱۳. مانیتورینگ و instrument و telemetry خیلی مهم تره.
۱۴. architecture design (خیلی مهم تره تا دیزاین پترن)
https://roadmap.sh/backend
کلا نمیدونم مشکل همه چیه با این رودمپ... خیلی کامل و دقیق گفته. فقط کلاد توش جا مونده.
roadmap.sh
Backend Developer Roadmap: What is Backend Development
Step by step guide to becoming a modern backend developer in 2025
👌8
Forwarded from CodeNaline | کدنالین
با مارک هماهنگ شد برای ۲ هفته دیگه :). اما چون تو این دو هفته بیکار نباشیم قراره یک اپیزود مشترک با مانی و بابی کلاود درباره مسیر رشد بکاند دولوپر داشته باشیم یک شنبه :). سوالاتتون در این مورد داخل کامنت ها همین پست لطفا بگید ❤️.
❤7⚡2👍1🔥1👌1
Forwarded from آموزش پایتون، دوآپس و مهندسی نرم افزار | BobyCloud (Boby Cloud)
✅ در ویدیو جدید بابی در نقش یک آتش نشان فداکار به سراغ مبحث تست نویسی در مهندسی نرم افزار میره و راجع به Smoke Test (تست دود) صحبت میکنه. همچنین یک نمونه Smoke Test با استفاده از سلنیوم در پایتون روی وبسایت LeetCode پیاده سازی میکنیم.
🔥 تست دود نوعی تست نرم افزار هست که پس از انجام تغییرات در نرم افزار انجام میشود تا اطمینان حاصل شود که ویژگی های اصلی نرم افزار به درستی عمل میکنند.
🖥 مشاهده در یوتوب
👉 Link: https://youtu.be/Mog3OaiSidE?si=Sgyo6udH4wQHWZNg
〰️〰️〰️〰️〰️〰️
@BobyDotCloud
🔥 تست دود نوعی تست نرم افزار هست که پس از انجام تغییرات در نرم افزار انجام میشود تا اطمینان حاصل شود که ویژگی های اصلی نرم افزار به درستی عمل میکنند.
🖥 مشاهده در یوتوب
👉 Link: https://youtu.be/Mog3OaiSidE?si=Sgyo6udH4wQHWZNg
〰️〰️〰️〰️〰️〰️
@BobyDotCloud
❤5
Forwarded from Nima Tech Talk 💻
پیاده سازی عجیب و زیبای درهم تنیدگی در وب به کمک لوکال استوریج
Entanglement implementation in web
https://x.com/_nonfigurativ_/status/1727322594570027343?s=46
Entanglement implementation in web
https://x.com/_nonfigurativ_/status/1727322594570027343?s=46
یک پلی لیست به نظر خوب از دانشگاه MIT سال ۲۰۲۰ در مبحث distributed systems
(خودم میخام نگاه کنمش )
https://m.youtube.com/watch?v=cQP8WApzIQQ&list=PLrw6a1wE39_tb2fErI4-WkMbsvGQk9_UB&index=1&pp=iAQB
@TorhamDevCH
(خودم میخام نگاه کنمش )
https://m.youtube.com/watch?v=cQP8WApzIQQ&list=PLrw6a1wE39_tb2fErI4-WkMbsvGQk9_UB&index=1&pp=iAQB
@TorhamDevCH
YouTube
Lecture 1: Introduction
Lecture 1: Introduction
MIT 6.824: Distributed Systems (Spring 2020)
https://pdos.csail.mit.edu/6.824/
MIT 6.824: Distributed Systems (Spring 2020)
https://pdos.csail.mit.edu/6.824/
⚡4💯1
TorhamDev | تورهام 😳
https://www.linkedin.com/posts/hamed-aghili-954244247_%D8%AA%D8%AC%D8%B1%D8%A8%D9%87-%DB%8C-%D8%A8%D8%AF-%D9%85%D9%86-%D8%A8%D8%A7-%D8%B4%D8%B1%DA%A9%D8%AA-%D8%AA%D8%B1%DA%A9%DB%8C%D9%87-%D8%B1%D9%87%DB%8C%D8%A7%D8%A8-%D8%AF%D9%88%D8%B3%D8%AA%D8%A7%D9%86-activity…
اولین شرکت من هم کلاه برداری بود چندین بار داخل پادکست و جاهای مختلف گفتم :). توصیه من همیشه این بوده حتی اگه هنوز سابقه ندارید و اولین شرکتتونه. اگر حقوقتون همون ماه اول ندادن و شروع به وضع قانون و چیزا و بهونه آوردن کردن دیگه حتی یک خط کد هم نباید براشون بزنید. مطمعن باشید بازم میتونید کار پیدا کنید چون همیشه برای کسی علم و دانش و تخصصش رو داره همیشه کار هست.
همیشه آرامش روانی و روحیتون ارجحيت داره به کار. ( این بعد چند سال واقعا بهش رسیدم )
همیشه آرامش روانی و روحیتون ارجحيت داره به کار. ( این بعد چند سال واقعا بهش رسیدم )
👍32
Forwarded from Sudoer (Morteza Bashsiz)
درود بر همه شما دوستان عزیز
یه موضوعی هست که بدون شک قبولش دارم
من یه باگی رو توی ورژن جدید Ceph ثبت کردم و یکی اومد بهم پاسخ داد که این باگ قبلا مطرح شده بود و توی نسخه بعدی برطرف خواهد شد
بعد رفتم گیتهاب اون بنده خدا رو که بهم پاسخ داده بود نگاه کردم خودش کسی بود که پولریکوست فیکس باگ رو داده بود و باگ رو برطرف کرده بود
کلا ۷ نفر فالوش میکنن و ۴ نفر رو فالو میکنه ولی توی پروژه بزرگی مثل Ceph داره کانتریبیوت میکنه و تو کمپانی IBM مشغول به کار هست
با Shell, Golang, Python, Java, C++ i هم کد میزنه
بعد کد هم میزنه نه اینکه الکی بزنه همه پروژههای بزرگ داره کد میزنه
حالا یکی مثل من که هیچ دانش درستحسابی هم نداره و صرفا چندتا ابزار رو یکم بلده دیگه چه حرفی دارم جلوی باسوادهای واقعی بزنم؟
میخوام بگم که به لایک و کامنت و فالوور و پوشیدن شلوارک و پیرجامه و آبنبات و بادکنک و زدن حرفای سکسی فنی نیست
برید ببینید طرف چقدر تاثیرگذار هست و چقدر کار بلده
به این شوآفیها بها ندید و بزرگشون نکنید
مرتضی باشسیز
یه موضوعی هست که بدون شک قبولش دارم
من یه باگی رو توی ورژن جدید Ceph ثبت کردم و یکی اومد بهم پاسخ داد که این باگ قبلا مطرح شده بود و توی نسخه بعدی برطرف خواهد شد
بعد رفتم گیتهاب اون بنده خدا رو که بهم پاسخ داده بود نگاه کردم خودش کسی بود که پولریکوست فیکس باگ رو داده بود و باگ رو برطرف کرده بود
کلا ۷ نفر فالوش میکنن و ۴ نفر رو فالو میکنه ولی توی پروژه بزرگی مثل Ceph داره کانتریبیوت میکنه و تو کمپانی IBM مشغول به کار هست
با Shell, Golang, Python, Java, C++ i هم کد میزنه
بعد کد هم میزنه نه اینکه الکی بزنه همه پروژههای بزرگ داره کد میزنه
حالا یکی مثل من که هیچ دانش درستحسابی هم نداره و صرفا چندتا ابزار رو یکم بلده دیگه چه حرفی دارم جلوی باسوادهای واقعی بزنم؟
میخوام بگم که به لایک و کامنت و فالوور و پوشیدن شلوارک و پیرجامه و آبنبات و بادکنک و زدن حرفای سکسی فنی نیست
برید ببینید طرف چقدر تاثیرگذار هست و چقدر کار بلده
به این شوآفیها بها ندید و بزرگشون نکنید
مرتضی باشسیز
👍15👎3❤2
Forwarded from Python BackendHub
دیشب صدرا یک سوال خوب پرسید, امشب نوبت منه که یک سوال میلیون دلاری بپرسم :)) خودتونو تو این شرایط قرار بدین:
یک conflict دارین با تصمیم گیرنده. حالا تیم لید باشه یا هرکی کاری ندارم. فکر میکنید که شما روشتون اصولی تره و درست تره ولی اون موافق نیست و میگه <فعلا نیازی نیست> شرایطی که شاید خیلیاتون تو ایران بهش برخوردین.
مثلا:راجب تست نویسی. بیشتر تست کنیم, کدو ریفکتور کنیم بهتر شه. تمیز تر شه. یا چیزای این قبیلی.
چطور conflictتون رو حل میکنید؟
هنر رفع conflict مهم ترین سافت اسکیله به نظره من!
@ManiFoldsPython
یک conflict دارین با تصمیم گیرنده. حالا تیم لید باشه یا هرکی کاری ندارم. فکر میکنید که شما روشتون اصولی تره و درست تره ولی اون موافق نیست و میگه <فعلا نیازی نیست> شرایطی که شاید خیلیاتون تو ایران بهش برخوردین.
مثلا:راجب تست نویسی. بیشتر تست کنیم, کدو ریفکتور کنیم بهتر شه. تمیز تر شه. یا چیزای این قبیلی.
چطور conflictتون رو حل میکنید؟
هنر رفع conflict مهم ترین سافت اسکیله به نظره من!
@ManiFoldsPython
👍1
Forwarded from Python BackendHub
یک سری نظرا رو شنیدم. من نظره خودمو میگم که بیشتر بحث کنیم, ببینید وقتی conflict وجود داره چند اشتباه ممکنه دو طرف بکنند که بهتره بررسیشون کنیم:
۱. اینپوت شما همیشه باید خیلی با ارزش باشه. با ارزش بودن به این دلیل نیست که حتما قبول شه. به این دلیله که شنیده شه و حتی راجبش بحث شه یا جلسه گذاشته شه. غیر این باشه محیطی نیست که توش بتونید پیشرفت کنید. ممکنه همه input هاتونم ریجکت شه و این موضوعو نباید سوءبرداشت شخصی ازش داشته باشین. پس اگه جای تصمیم گیرنده هستین این حس با ارزش بودن اینپوت و شنیدنشو منتقل کنید. فیدبک ها همیشه باعث بهتر شدن یک سیستم میشن.
۲. همیشه فکر میکنن ۲ تا نقطه مقابل هم وجود داره تو conflict در صورتی که اصلا اینطور نیست. مثلا کارفرما میگه اقا من این پروداکتو باید تا فلان روز برسونم سریع کدشو بزن. شمام میگی نه ریفکتور میخواد اصولی نیست. منتهی تو این سناریو یک راه حل سومی هست: که شما با اون فرد بشینی مذاکره کنی و بحث کنی. ممکنه یک نقطه وسط برسین. در درجه اول باید درک کنید طرف مقابل چی میگه. در درجه دوم راهکار خودتونو به نحوی بچرخونید که با هدف اون همسو باشه. مثلا این arguement اش این میشه که اقا من باید رو هر فیچر جدید دستی تست کنم که کار میکنه. من argue میکنم که اگه تست خودکار بنویسم وقت کمتری مصرف میکنم. پس نظرت چیه شرط ببندیم برای این فیچر جدید که من سریعتر میرسونم با داشتن تست؟ سرعت توسعه منو بیشتر میکنه. یا مثلا بگین اقا من این قسمت جدیدی که دارم اضافه میکنم رو تمیز کد میزنم. کاری ندارم به بقیه. و کارمو هم سریع تر میرسونم. ممکنه کد consistent نشه و یک دفعه خیلی متفاوت شه ولی بهترین راه کاره. اینطوری هم کارو سریع میرسونم هم کم کم ریفکتور میشه با فیچر های جدید تری که اضافه میکنیم به این پروژه.
۳. سطح علمی طرف مقابل رو در نظر نمیگیرین و یا pros یا cons رو خوب نمیگن. من به عنوان یک مهندس نرم افزار وظیفه دارم long time side effect این کار اشتباهو بگم. که تصمیم گیرنده درک بهتری داشته باشه. از حرفام با سند و مدرک و مقاله دفاع کنم. صرفا حرف شما به تنهایی ممکنه اعتبار نداشته باشه. همیشه وقتی یک بحثی میکشین وسط یادتون باشه هم pros باید گفته شه هم cons که شنونده احساس نکنه شما دارین احساسی تصمیم میگیرین و منطقی تصمیم گرفته شه.
۴. سعی کنید brain storming کنید. سعی کنید حوادث رو ارتباط بدین با مشکلی که دارین. مثلا بگین فلان باگ و فلان باگ و فلان باگ به وجود اومد چون اینکارا رو نکردیم. پس بهتره بکنیم. هیچوقت یارکشی نکنید. بگید فلانی همیشه conflict منو رد میکنه یا فلان. این بد ترین چیزیه تو یک تیم. یادتون باشه اینپوتتون قرار نیست همیشه قبول شه. ولی باید با ارزش باشه. یک کامنتی خیلی قشنگ نوشتن: قاتل کار تیمی miscommunicationعه! و برعکسش هم صدق میکنه. برای همین brain storming خیلی میتونه مفید باشه.
۵. از دنیای فانتری فاصله بگیرین. واقعبین باشید. مثلا دیدم برنامه نویسا یک فریم ورک یا یک فیچر اصلا به دردشون نمیخورد ولی اضافه کردن چرا؟چون خوششون میاد. چون میخوان یادش بگیرن. این بد ترین کاریه که میتونید تو یک محیط حرفه ای کنید. یا مثلا میرن premature optimization انجام میدن و وقتشونو هدر میدن برای جایی که اصلا نیازی نبوده. یا بیش از حد کلین کد میزنن رو پروداکتی که requirement اش روز به روز تغییر میکنه. پس همیشه سعی کنید از دید model business پروداکتتون به محصولتون نگاه کنید تا بهترین کد هارو بنویسید 🙂 خیلی وقتا دلیل conflict همینه که یکی از دو طرف تو دنیای فعلی نیست.
@ManiFoldsPython
۱. اینپوت شما همیشه باید خیلی با ارزش باشه. با ارزش بودن به این دلیل نیست که حتما قبول شه. به این دلیله که شنیده شه و حتی راجبش بحث شه یا جلسه گذاشته شه. غیر این باشه محیطی نیست که توش بتونید پیشرفت کنید. ممکنه همه input هاتونم ریجکت شه و این موضوعو نباید سوءبرداشت شخصی ازش داشته باشین. پس اگه جای تصمیم گیرنده هستین این حس با ارزش بودن اینپوت و شنیدنشو منتقل کنید. فیدبک ها همیشه باعث بهتر شدن یک سیستم میشن.
۲. همیشه فکر میکنن ۲ تا نقطه مقابل هم وجود داره تو conflict در صورتی که اصلا اینطور نیست. مثلا کارفرما میگه اقا من این پروداکتو باید تا فلان روز برسونم سریع کدشو بزن. شمام میگی نه ریفکتور میخواد اصولی نیست. منتهی تو این سناریو یک راه حل سومی هست: که شما با اون فرد بشینی مذاکره کنی و بحث کنی. ممکنه یک نقطه وسط برسین. در درجه اول باید درک کنید طرف مقابل چی میگه. در درجه دوم راهکار خودتونو به نحوی بچرخونید که با هدف اون همسو باشه. مثلا این arguement اش این میشه که اقا من باید رو هر فیچر جدید دستی تست کنم که کار میکنه. من argue میکنم که اگه تست خودکار بنویسم وقت کمتری مصرف میکنم. پس نظرت چیه شرط ببندیم برای این فیچر جدید که من سریعتر میرسونم با داشتن تست؟ سرعت توسعه منو بیشتر میکنه. یا مثلا بگین اقا من این قسمت جدیدی که دارم اضافه میکنم رو تمیز کد میزنم. کاری ندارم به بقیه. و کارمو هم سریع تر میرسونم. ممکنه کد consistent نشه و یک دفعه خیلی متفاوت شه ولی بهترین راه کاره. اینطوری هم کارو سریع میرسونم هم کم کم ریفکتور میشه با فیچر های جدید تری که اضافه میکنیم به این پروژه.
۳. سطح علمی طرف مقابل رو در نظر نمیگیرین و یا pros یا cons رو خوب نمیگن. من به عنوان یک مهندس نرم افزار وظیفه دارم long time side effect این کار اشتباهو بگم. که تصمیم گیرنده درک بهتری داشته باشه. از حرفام با سند و مدرک و مقاله دفاع کنم. صرفا حرف شما به تنهایی ممکنه اعتبار نداشته باشه. همیشه وقتی یک بحثی میکشین وسط یادتون باشه هم pros باید گفته شه هم cons که شنونده احساس نکنه شما دارین احساسی تصمیم میگیرین و منطقی تصمیم گرفته شه.
۴. سعی کنید brain storming کنید. سعی کنید حوادث رو ارتباط بدین با مشکلی که دارین. مثلا بگین فلان باگ و فلان باگ و فلان باگ به وجود اومد چون اینکارا رو نکردیم. پس بهتره بکنیم. هیچوقت یارکشی نکنید. بگید فلانی همیشه conflict منو رد میکنه یا فلان. این بد ترین چیزیه تو یک تیم. یادتون باشه اینپوتتون قرار نیست همیشه قبول شه. ولی باید با ارزش باشه. یک کامنتی خیلی قشنگ نوشتن: قاتل کار تیمی miscommunicationعه! و برعکسش هم صدق میکنه. برای همین brain storming خیلی میتونه مفید باشه.
۵. از دنیای فانتری فاصله بگیرین. واقعبین باشید. مثلا دیدم برنامه نویسا یک فریم ورک یا یک فیچر اصلا به دردشون نمیخورد ولی اضافه کردن چرا؟چون خوششون میاد. چون میخوان یادش بگیرن. این بد ترین کاریه که میتونید تو یک محیط حرفه ای کنید. یا مثلا میرن premature optimization انجام میدن و وقتشونو هدر میدن برای جایی که اصلا نیازی نبوده. یا بیش از حد کلین کد میزنن رو پروداکتی که requirement اش روز به روز تغییر میکنه. پس همیشه سعی کنید از دید model business پروداکتتون به محصولتون نگاه کنید تا بهترین کد هارو بنویسید 🙂 خیلی وقتا دلیل conflict همینه که یکی از دو طرف تو دنیای فعلی نیست.
@ManiFoldsPython
👍1
Forwarded from Python BackendHub
بعد توضیح اینا تو یک پاسخ خیلی کوتاه, من چیکار میکنم موقع conflict؟
۱. سعی میکنم اشتباهاتی که بالاتر اشاره کردم نکنم
۲. سعی میکنم به یک نقطه اشتراک برسم بعد از درک طرف مقابلم و ببینم دلیل تصمیمش و مخالفتش چیه؟
۳. سعی میکنم نظر بقیه هم بپرسم و یک brain storming انجام بدم به مشکل.
۴. اگه راهکاری معرفی شه توسط خودم یا یکی از تیم که هم نقاط نظر من و هم conflict دهنده توش رعایت شده باشه انجام میدیم. اگه نه , جمع بندی رو یک جایی ظبط میکنم که بدونیم همچین conflict ای بوده قبلا که از این مشکلات ناشی میگیره و راهکاری براش هنوز پیدا نکردیم که بعدا دوباره فکر کنیم بهش.
در نهایت conflict اینطوری برطرف میشه.
@ManiFoldsPython
۱. سعی میکنم اشتباهاتی که بالاتر اشاره کردم نکنم
۲. سعی میکنم به یک نقطه اشتراک برسم بعد از درک طرف مقابلم و ببینم دلیل تصمیمش و مخالفتش چیه؟
۳. سعی میکنم نظر بقیه هم بپرسم و یک brain storming انجام بدم به مشکل.
۴. اگه راهکاری معرفی شه توسط خودم یا یکی از تیم که هم نقاط نظر من و هم conflict دهنده توش رعایت شده باشه انجام میدیم. اگه نه , جمع بندی رو یک جایی ظبط میکنم که بدونیم همچین conflict ای بوده قبلا که از این مشکلات ناشی میگیره و راهکاری براش هنوز پیدا نکردیم که بعدا دوباره فکر کنیم بهش.
در نهایت conflict اینطوری برطرف میشه.
@ManiFoldsPython
Forwarded from Python BackendHub
این سوال مصاحبه behavioural خیلی از شرکتا هست. خیلیم قشنگ میتونن خیلی پیچیده ترش کنند و به چالش بکشنتون. حتما رو این صورت سوال خیلی فکر کنید. برای career خودتونم خیلی مهمه. جواب من ممکنه درست باشه ممکنه درست نباشه. برای همین کامنت گرفتم اول که ببینم بقیه چیکار میکنن. اگه موافقین/مخالفین خوشحال میشم کامنت کنید و شرکت کنید تو بحث.
@ManiFoldsPython
@ManiFoldsPython
👍2