.
هر دو آقای گُلند.
اما این کجا و آن کجا!

sora.chatgpt.com

✍🏽 ¦ @DevYara

تو مثل پرانتزی() همیشه تو معادله ها اولویتمی!❤️

✍🏽 ¦ @DevYara

یه جمله ای که الان شنیدم یه ایده میلیون دلاری از استاد دانشگاهمون

"میگه که در آینده نمیدونم اینا میخوان چی درست کنن مثلا میان سخت افزار رو حذف میکنن فقط میرن تو کار نرم افزار"
✍🏽 ¦ @DevYara

سؤال مصاحبه برای موقعیت Team Lead :

این یکی از سوالاتی‌ست که ممکن است در مصاحبه موقعیت شغلی رهبر تیم (Team Lead) مطرح شود. هر کس می‌تواند بر اساس تجربه شخصی خودش به آن پاسخ دهد.

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

✍🏽 ¦ @DevYara ¦ #سوال_مصاحبه

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

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

2. اعتماد به کد، فراتر از خود زبان
اینکه یک زبان قابل اعتماده، خیلی وقت‌ها به مهارت برنامه‌نویس بستگی داره، نه صرفاً خود زبان. مثلاً با اینکه Haskell زبانی بسیار قویه، ممکنه خروجی‌های ناامن هم با اون نوشته بشه، اگر توسعه‌دهنده باهاش آشنا نباشه.

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

4. تعداد به‌تنهایی نشان‌دهنده کیفیت نیست
اینکه یه پکیج npm هزاران استار داره، لزوماً نشون‌دهنده امنیت یا کیفیت بالا نیست. همیشه بهتره کدها رو بررسی کرد، چون تجربه نشون داده که حتی محبوب‌ترین پکیج‌ها هم ممکنه آسیب‌پذیری داشته باشن.

5. پیچیدگی همیشه بد نیست
ساده بودن یه زبان همیشه به‌معنای خوب بودنش نیست. باید دید پیچیدگی چه امکاناتی رو فراهم کرده. مثلاً Go زبانی ساده‌ست اما بسیار کارآمده. یا JavaScript سریع یاد گرفته می‌شه، ولی هیچ تضمینی برای خروجی درست وجود نداره!

6. پارادایم‌ها و برداشت‌های اشتباه
تصورات اشتباهی مثل "OOP سریعه و FP کنده" زیاد دیده می‌شن، اما بستگی به پیاده‌سازی داره. مثلاً FP در Haskell می‌تونه از Java یا #C سریع‌تر باشه. پارادایم‌ها بیشتر به سبک سازمان‌دهی کد مربوط می‌شن تا سرعت.

7. بنچمارک‌ها و پشت‌پرده‌ی عملکرد
هر زبان، بهینه‌سازی‌های خاص خودش رو داره. مثلاً ترتیب فیلدهای object در JS روی سرعت تأثیر می‌ذاره یا در زبان‌های تابعی، کامپایلر می‌تونه بازگشت دنباله‌دار رو به loop تبدیل کنه. پس مقایسه عملکرد، نیاز به تحلیل چندبُعدی داره، نه فقط عدد خام.
✍🏽 ¦ @DevYara

سؤال برای توسعه‌دهندگان فرانت‌اند:

تفاوت بین System Design و Design System چیست؟

#سوال_مصاحبه‌
✍🏽 ¦ @DevYara

نسل جدید به هیچ وجه این عکس‌ رو درک نمیکنه...

✍🏽 ¦ @DevYara

به‌نظرتون کدوم کار یه برنامه‌نویس جوگیر انجام می‌ده که از هر نظر مبتدی و ضایع به‌نظر می‌رسه؟
✍🏽 ¦ @DevYara

تجربه‌تون از فضای دانشگاه چطور بوده؟ چه چیزهایی یاد گرفتین، چه مهارت‌ها یا اتفاقات خاصی براتون افتاده، و نگاه کلی‌تون به دانشگاه و محیطش چیه؟
✍🏽 ¦ @DevYara

دارک وب ❌
نی‌نی سایت ✅
✍🏽 ¦ @DevYara

همکار ابدی 🤣

✍🏽צ @DevYara

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

ولی نکته‌ش اینه که زمانی که زیاد فکر می‌کنی که می‌خوای چه جوابی بدی، مثلاً به ظاهر بهترین جواب رو بدی، معمولاً نتیجه چیزی که فکر می‌کنی نمی‌شه!

همین موضوع رو رفتم به یه استاد روانشناسی که هم‌ باشگاهی من هست گفتم، و اون چیزی که به من گفت این بود که این مشکل از کمال‌گرایی توئه؛ که دنبال بهترین جمله‌ای، و این خیلی بده.
کاری که می‌تونی بکنی اینه که اولین چیزی که توی ذهنت میاد رو بگی یا انجام بدی، چون ناخودآگاهت از خودآگاهت باهوش‌تره و کار رو باید بسپاری به اون.

نهایتش اینه که حرفت رو راحت می‌زنی. در بدترین حالت، طرف ناراحت میشه یا بهش برمی‌خوره؛ که مهم نیست، یه معذرت‌ خواهی می‌کنی یا منظورت رو می‌رسونی.
ولی اگه هیچی نگی یا زیاد فکر کنی، فرصت رو از دست میدی.

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

✍🏽 ¦ @DevYara

پخش کردن این ویدئو باعث می شه تلگرام [موبایل] کرش کنه و بسته بشه!

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

نمونه‌های مشابه زیاد بودن و هستن و در بهترین حالت باعث بسته شدن این برنامه می‌شن. در حالت‌های «بدتر»‌ ممکنه مثلا باعث یه لوپ بینهایت بشن که دستگاه رو نیازمند ریبوت سخت افزاری کنه یا مثلا می گن «این عکس رو بذارین عکس والپیپر موبایل تا...» و وقتی می ذارین هر بار که دستگاه بوت می شه، کرش می‌کنه (: یا مثلا اگر یه متن باشه می تونین بفرستین به یه نفری و موبایلش کرش کنه بدون اینکه حتی بهش دست بزنه (:

خلاصه لذتش رو ببرین و بخندین تا با آپدیتی سریع حل بشه.

۲۳ دقیقه و ۱۵ ثانیه ⏳

به‌عنوان یک برنامه‌نویس می‌تونم بگم که کار ما نیاز به تمرکز عمیق (deep focus) داره.
حواس‌پرتی به‌خاطر عوامل بیرونی، این تمرکز رو به‌هم می‌زنه.

برای برگشتن به حالت "تمرکز عمیق" بعد از حواس‌پرتی، ۲۳ دقیقه و ۱۵ ثانیه زمان نیازه.
تصورش رو می‌کنی؟ ما معمولاً هر ۱۵ دقیقه یک‌بار حواسمون پرت میشه.

یعنی خیلی کم وارد "تمرکز عمیق" می‌شیم.
توصیه من اینه که حواس دیگران رو پرت نکن و عوامل حواس‌پرتی خودت رو هم دور کن.

این پیام رو برای کسی بفرست که زیاد حواست رو پرت می‌کنه ✈️
✍🏽 ¦ @DevYara

چیزی که در Claude 4.0 بیشتر از همه خوشم اومد اینه که موقع کدنویسی اصلاً کامنتهای اضافی نمینویسه.

مدل های قبلی انگار برای یه بچه ۷ ساله توضیح میدادن، پر از توضیح‌های اضافی و غیرضروری بودن.