نوشته های Amir Mirkamali

سؤالات عجیب (Fermi Questions) در مصاحبه‌ها و نحوه‌ی پاسخگویی به آنها

Amir Mirkamali — Wed, 24 Dec 2025 08:18:29 +0330

این اواخر در شبکه های اجتماعی چند نفر را دیدم که از سؤالات عجیب در مصاحبه‌ها گله داشتند. سؤالاتی که در ظاهر خیلی عجیب هستند و ربطی به تخصص ما (نرم افزار و برنامه نویسی) ندارند ولی برای سنجش برخی توانایی‌های شما پرسیده می شوند.سؤالاتی مثل این‌ها:چند پیانو در شهر تهران وجود دارد؟چند لیوان آب در طول عمرت می‌نوشی؟در یک روز چند نفر در ایران موهایشان را کوتاه می‌کنند؟چند دانه برنج در یک کیسه ۱۰ کیلویی است؟فصل مشترک این سؤال‌ها این است که هیچ‌کدام جواب دقیق ندارند، اما می‌شود تخمین زد.به این سؤالات Fermi Questions گفته می شود. Fermi Questions (سؤالات فرمی) به سؤال‌هایی گفته می‌شود که پاسخ دقیق آن‌ها را نمی‌دانیم یا دادهٔ دقیقی نداریم، اما می‌توانیم با تقریب زدن منطقی و مرحله‌به‌مرحله، به یک جواب معقول برسیم.این مفهوم از انریکو فرمی (Enrico Fermi)، فیزیک‌دان معروف، گرفته شده است که به خاطر توانایی فوق‌العاده‌اش در تخمین‌های سریع و هوشمندانه معروف بود.ویژگی‌های اصلی Fermi Questionsجواب دقیق ندارند، بلکه تقریبی هستندبا شکستن مسئله به چند فرض ساده حل می‌شوندهدفشان نحوه فکر کردن است، نه عدد نهاییمعمولاً در مصاحبه‌ها، آموزش تفکر تحلیلی و علم داده استفاده می‌شوند.وقتی با این سؤالات مواجه شدید توجه کنید که مصاحبه‌کننده عدد دقیق نمی‌خواهد، بلکه می‌خواهد ببیند:آیا مسئله را می‌شکنی؟آیا فرض‌هایت منطقی است؟آیا مسیر فکری‌ات شفاف و قابل دفاع است؟یک نمونه ای که من شیندم این بود که چند درخت در خیابان ولی عصر وجود دارد؟بیایید که این را با هم حل کنیم. برای حل مساله به موارد زیر احتیاج داریم:طول خیابان را بدانیمفاصله تقریبی درخت‌ها را تخمین بزنیمدو طرف خیابان را در نظر بگیریمشاید جاهایی بدون درخت وجود داشته باشدطول خیابان ولیعصراز میدان راه‌آهن تا میدان تجریش ≈ ۱۸ کیلومتردو طرف خیابان درخت داردپس طول مؤثر:۱۸ × ۲ = ۳۶ کیلومترفاصله‌ی متوسط بین درخت‌هادر شهر معمولاً بین ۵ تا ۸ مترفرض منطقی: ۶ متر محاسبه خامتبدیل به متر:۳۶ کیلومتر = ۳۶٬۰۰۰ مترتعداد درخت۳۶٬۰۰۰ ÷ ۶ ≈ ۶٬۰۰۰ درختنکات تکمیلیهمه جا درخت نیست:تقاطع‌هاپل‌هاایستگاه‌هاجاهای خشک‌شده یا حذف‌شدهپس مثلاً ۲۰٪ کاهش:۶٬۰۰۰ × ۰٫۸ = ۴٬۸۰۰جواب نهایی حرفه‌ایبا فرض طول ۱۸ کیلومتر برای خیابان، وجود درخت در دو طرف، فاصله‌ی متوسط ۶ متر بین درخت‌ها و در نظر گرفتن حذف درخت‌ها در تقاطع‌ها، می‌توان تخمین زد حدود ۵ هزار درخت در خیابان ولیعصر وجود دارد. البته اگر داده‌ی واقعی شهرداری یا تصاویر ماهواره‌ای داشته باشیم، می‌توان این تخمین را دقیق‌تر کرد.توجه کنید که در این سؤالات روش حل مساله و شیوه تقسیم مساله به مساله‌های کوچک تر و توانایی شما در تحلیل مهم است نه جواب نهایی.

آیا از CSS Framework ها مانند Tailwind یا Bootstrap استفاده کنیم یا نه؟

Amir Mirkamali — Sun, 18 Aug 2024 09:33:05 +0330

وقتی در شروع یک پروژه هستید، شاید این سوال برای شما پیش آمده باشد که آیا از CSS Framework ها مانند tailwind و bootsrap استفاده کنم یا اینکه همه استایل‌ها را خودتان بنویسید.صدالبته هرکدام معایب و مزایایی دارد. برخی از آنها را با هم بررسی می کنیم.استفاده از Vanilla CSS یا همان عدم استفاده از CSS Framework هاوقتی از هیج فریمورکی استفاده نمی کنید، طبیعتا کنترل همه چیز در اختیار شماست و چیزی شما را محدود نخواهد کرد. ولی طبیعتا برای تازه‌کاران ممکن است چالش‌هایی داشته باشد و پیچیدگی‌هایی ایجاد کند ولی بعد از مدتی همه چیز عادی خواهد شد.استفاده از این روش تسلط شما را روی CSS بالا خواهد برد و به مرور زمان از کسانی که از اول از CSS Framework استفاده کرده اند مسلط‌تر و حرفه‌ای تر خواهید بود. بعضا در استخدام ها می‌بینم که بعضی از دولوپرها بخاطر استفاده از همین فریمورک‌ها اصلا دید درستی نسبت به علت و تنوع عملکرد مشخصات در CSS ندارند. نکته ی جالب اینکه گهگاه حتی به من می‌گویند که استفاده از CSS خام کاری عبث و بیهوده است.نکته ی بعدی اینکه در صورت عدم استفاده در بخش CSS ها باید توان بیشتری بگذارید و کد بیشتری بنویسید ولی در بحث حجم کلی پروژه باید بگویم که حتما به نفع شما خواهد بود و سرعت Render هم به طرز قابل ملاحظه‌ای بیشتر و بهتر است.البته تجربه به من می گوید که شما اگر از این روش هم پیش بروید کم کم خودتان به یک CSS Framework شخصی دست پیدا خواهید کرد.پیشنهاد من این است که برای پروژه‌های کوتاه مدت از این روش استفاده نکنید ولی اگر پروژه ی بزرگی دارید به نظر من سراغ فریمورک‌ها نروید. اگر دیزاین سیستم خودتان را دارید این روش ناگزیر است و سایر روش‌ها کمی شما را اذیت خواهند کرد.اگر می خواهید یک پروژه را سرعتی انجام بدهید و خیلی درگیر CSS نشوید، این روش برای شما مناسب نیست.استفاده از CSS Framework هاقطعا سرعت Develop در این روش سریع‌تر خواهد بود ولی حجم فایل های نهایی بیشتر می شود و سرعت رندر هم کم می شود چون استایل ها و کدهای جاواسکریپتی ناخواسته در گوشه و کنار وجود دارند و همین باعث کندتر شده رندر شما خواهند شد.یک نکته ی مثبت اینکه همه ی کسانی که روی یک framework خاص کار کرده‌اند زبان مشترکی دارند و اگر در تیم‌ها جابجا شوند، خوشبختانه مشکلی پیش نمی آید چون استانداردی که مثلا Tailwind دارد برایشان آشنا است.یک نکته ی دیگر اینکه به نظر من اغلب سایت هایی که از این فریمورک‌ها استفاده می کنند بعد از مدتی به نوعی شبیه هم می شوند (نظر شخصی) و تقریبا قابل حدس هستند.تجربه بد بعدی نیز این است که اگر نسخه ی جدید بیاید، شما مجبور به بروزرسانی هستید و این بروزرسانی دردناک است! من تجربه بروزرسانی در bootstrap را داشته ام که واقعا ناراحت کننده است (از نسخه های قدیمی مثل ۳ با آخرین ورژن)در بحث خطایابی و بررسی علت عملکردها برخی کامپوننت‌ها و استایل‌ها، کار کمی سخت‌تر است چون برخی قوانین در بدنه و Core قرار دارند و برخی نیز ممکن است توسط شما ویرایش شده باشند. استفاده از important هم واقعا trace کردن خطا را سخت می کند.مشکل بعدی این است که گاه و بیگاه یک مشکل امنیتی در آنها ممکن است پیش بیاید و شما مجبور به بروز رسانی هستید و این هم خودش یک مساله است و ممکن است پکیج های دیگری داشته باشید که با این بروزرسانی ها سازگار نباشند و خلاصه به قول قدیمی‌ها دردسر می شود!البته اینکه با آپدیت ها فیچر جدید به کارتان اضافه می شود را نباید فراموش کنیم که خیلی احساس خوبی به Developer ها می دهد (بدون تلاش فیچر جدید دارید)البته به نظر من Tailwind بسیار عالی و کاربردی است و قابل سفارشی سازی و منعطف است و در این شاخه فعلا از بهترین انتخاب‌ها است. البته کمی طول می کشد که روی آن مسلط شوید ولی ارزش وقت گذاشتن را به نظر من دارد.جمع بندیپیشنهاد من به شما این است که در هر شاخه‌ای از وب که کار می کنید، سعی کنید که دید عمیق داشته باشید ولی توجه داشته باشید، همیشه زمان و هزینه در انتخاب مسیر بسیار تعیین کننده هستند.با این توضیح به نظر من استفاده از CSS Framework ها فقط وقتی که روش اول در دسترس نیست، خوب است. یعنی یا وقت ندارید یا واقعا CSS و ظاهر خیلی نقض مهمی در پروژه ندارد، یا اینکه بودجه کافی برای این کار ندارید، سراغ فریمورک‌ها بروید، وگرنه اگر می خواید Developer بهتری باشید و دست‌تان هم باز باشد و کمتر به مشکل بربخورید، پیشنهاد من استفاده از Vanilla CSS یا همان عدم استفاده از فریمورک‌ها است.

مشکل عدم نمایش درست Typeهای ترکیبی Typescript در هنگام استفاده در VSCode

Amir Mirkamali — Sat, 17 Aug 2024 14:41:18 +0330

یک نکته‌ی جالبی در تعریف تایپ‌ها در typescript برخوردم که گفتم اینجا هم یک یادداشتی برای آن بنویسم.وقتی که یک type تعریف می کنید که این تایپ، چند مقدار ثابت به همراه یک تایپ عمومی باشد، هنگام autocomplete در ادیتور فقط تایپ عمومی را می آورد. همیشه برای من سوال بود که چرا وقتی من از این مدل type ها تعریف میکنم، مقادیر ثابت را در هنگام استفاده نمی آورد.با یک مثال توضیح می دهم:فرض کنیم، تایپی که من تعریف می کنم چیزی شبیه این باشد:type Variants = 'h1' | 'h2' | string ;یعنی variant می تواند h1 یا h2 یا یک string باشد. اما متاسفانه چیزی که در موقع استفاده می بینیم چیزی شبیه این است:می بینید که h1 و h2 را نمی آورد. برای حل این مساله، باید تایپ را به صورت زیر تعریف کنید:type Variants = 'h1' | 'h2' | (string & {});و خروجی شما درست خواهد شد.می بینید که h1 و h2 را اینبار می آورد.

انتشار پروژه های Next.js با کمترین زمان Downtime

Amir Mirkamali — Mon, 05 Aug 2024 09:43:35 +0330

Deploy Next.js Project Without Downtimeاگر از Next.js استفاده می کنید، و اپلیکیشن خودتان را می خواهید روی یک سرور اختصاصی اجرا و Deploy کنید، ممکن است به این مساله برخورده باشید که یک زمان Downtime کوچکی برای اپلیکیشن، هنگام به‌روزرسانی‌ها خواهید داشت.مهمترین بخش این Downtime به خاطر این است که باید کد شما یکبار روی محل انتشار پروژه ‌‌Build شود و این مورد اگر پروژه ی شما بزرگ باشد، طول می‌کشد و کاربر در این زمان نمی تواند از اپلیکیشن و سایت شما استفاده شود. اگر در سایت پرداخت الکترونیک داشته باشید هم این مشکل بیشتر خودش را نشان می‌دهد و نارضایتی کاربران را به دنبال خواهد داشت.اما راه حل:ابتدا کد خود (Branch نهایی) را آپلود کنید (یا اگر امکان نصب git روی هاست وجود دارد، با command های مرتبط کد را روی سرور به روز کنید)تنظیمات Next.js به شما اجازه می دهد که شاخه ای که قرار است Build در آن انجام شود را تغییر دهید. این خط را در فایل next.config.js خود بیفزایید:distDir: process.env.BUILD_DIR || '.next'با این خط به Builder می‌گوییم که شاخه ی Build همان پیش فرض خودش است، مگر اینکه من در command یک چیزی با پارامتر BUILD_DIR برای تو بفرستم.از این به بعد هر وقت خواستید Build انجام دهید با این command انجام دهید.BUILD_DIR=tempbuild npm run buildبعد از بیلد شدن در شاخه ی tempbuild می توانید شاخه ی next را پاک کنید و اسم این شاخه را به next تغییر دهید.rm -rf .nextmv tempbuild .nextبعد از این کار می توانید pm2 یا از هر چیزی که استفاده می کنید را ریستارت کنید تا تغییرات شما اعمال شوند.در بدترین حالت ۱ الی ۲ ثانیه Downtime خواهید داشت.

چگونه می‌توانیم API-Key را سمت کلاینت مخفی کنیم؟

Amir Mirkamali — Sat, 20 Jan 2024 12:02:48 +0330

مخفی کردن API Keyشاید برای شما هم این مساله پیش آمده باشد که چگونه API-Key ای که به ما، برای استفاده از یک سرویس Endpoint داده شده است را از دید کاربران سایت پنهان کنیم. اینکه API-Key اختصاصی شما توسط دیگران دیده شود، اصلا از لحاظ امنیتی جالب نیست.اول لازم است که کمی در مورد مساله توضیح بدهم. در صورتی که اپلیکیشن شما با استفاده از جاوااسکریپت بخشی از دیتای موردنظر خود را دریافت می کند، ممکن است که ارایه دهنده‌ی اطلاعات به شما یک API-Key بدهد که از طریق آن کنترل کند که چه کسی به دیتای ارایه شده دسترسی دارد یا حتی بخواهد تعداد درخواست‌های شما را کنترل کند. برای مثال شما یک اشتراک از weather.com برای دریافت وضعیت آب و هوای شهرهای جهان می‌خرید و سایت به شما یک API-Key می‌دهد و شما برای استفاده از این سرویس، باید در هر درخواست، این کد را در هدر درخواست‌های خود بفرستید.نکته: معمولا چنین سایت‌هایی اجازه ی ارسال درخواست از سمت کلاینت به شما نمی‌دهد (احتمالا خطای Cors خواهد داد) ، اما چرا؟ پاسخ ساده است، چون اگر شما API-Key را سمت کلاینت بگذارید، این کد توسط همه قابل رویت خواهد بود و به ازای هر ویزین سایت شما یک درخواست یه سمت سرور آنها می رود که چیز جالبی نیست.چطور بفهمیم آیا از API-Key استفاده شده است یا نه؟کافی است وقتی یک سایت را مشاهده می کنید، بخش Developer Tools را در مرورگر خود فعال کنید و در بخش Network درخواست‌های xhr را فیلتر کنید. و روی یک Request کلیک کنید و هدرها را ببینید. احتمالا چنین چیزی مشاهده خواهید کرد.اگر API-Key ارسال شود شما حتماً در هدرها، آن را مشاهده خواهید کرد. پس اگر API-Key دارید کاربران سمت کلاینت شما اصلا نباید آن را ببینند (سوای اینکه اگر از جای درستی API-Key گرفته باشید اصلا نمی‌گذارد شما آن را سمت کلاینت اجرا کنید، چون در واقع آن را با همه به اشتراک گذاشتید)در حالت کلی برای گرفتن اطلاعات عمومی سایت‌ها و اپلیکیشن ها، مانند اخبار و محصولات، خیلی سخت گیری نمی‌شود و شما مثل صفحات سایت می توانید آنها را با دانستن قالب Endpoint فراخوانی کنید و مساله ای هم ندارد. اما برای دیتای حساس نباید چنین باشد.راه حلاما راه حل چیست و چگونه نگذاریم که کسی API Key ما را ببیند؟ نکته ی اول: کلیدتان را تحت هیچ عنوان سمت کلایت نفرستید، به هیچ وجه! نه کد شده، نه عادی و نه به صورت پنهان. هرکاری کنید توسط کاربر کلاینت دیده می شود و خودتان را خسته نکنید. وقتی خیلی خیلی جوان بودم کلید را هر بار با یک متغیر وابسته به زمان کد می کردم (که مثلا کسی نفهمد) ولی چون الگوریتم کد کردن در اپلیکیشن شما سمت کلاینت می‌رود، باز هم کدگشایی خواهد شد. البته جلوی کاربران کم تجربه را می‌گیرید ولی هرکسی که کمی تجربه داشته باشد، کلید شما را استخراج می‌کند.چاره ی کار این است که این کار را سمت سرور انجام دهید. یعنی به اصطلاح یک پروکسی بنویسید. سعی می‌کنم بیشتر توضیح دهم. در واقع باید یک اپلیکیشن جدا سمت سرور بنویسید که درخواست‌ها را از کلاینت، به سمت آن اپلیکیشن بفرستید و آن اپلیکیشن سمت سرور، کلید را داشته باشد و درخواست‌ها از آن اپلیکیشن، به سرویس دهنده‌ی اصلی فرستاده شود و بعد از گرفتن پاسخ یا Response، آن را برای کلاینت بفرستد. در این صورت هیچکس از API-Key یا حتی قالب Endpoint های شما اطلاعی پیدا نخواهد کرد (یا اینکه شما از چه کسی سرویس گرفته‌اید) البته اگر از برخی فریمورک های جاوااسکریپتی مانند Next.js استفاده می کنید، میتوانید یک سری route handler در همان اپ خودتان بنویسید و خیلی کارتان راحت خواهد بود.این کار فواید دیگری هم دارد:می توانید درخواست‌ها را به تناسب Cache کنید که بسیار توصیه می شود.اگر سرویس دهنده عوض شود، شما لازم نیست که کدتان را سمت کلاینت تغییر دهید، فقط کافی است، بخش proxy را تغییر دهید.در پایان همیشه حواستان به امنیت اپلیکیشن‌تان باشد، هیچ وقت مسایل امنیتی را کم ارزش تلقی نکنید! به قول معروف ؛خیلی خطرناکه حسن 😁

هایدرشن - Hydration چیست؟ چگونگی حل مشکلات مربوط به آن در React

Amir Mirkamali — Fri, 05 Jan 2024 12:11:19 +0330

هایدریشن یک ایده مهم در توسعه وب است که این پتانسیل را دارد که عملکرد وب سایت را تا حد زیادی افزایش دهد.ایده ی کلی هایدرشن، به فرآیند گرفتن یک صفحه HTML ارائه شده در سمت سرور، و اتصال Event Listener ها و داده ها به آن در سمت کلاینت می پردازد. این روش، سرعت رندر سریعتر، و تجربه کاربری بهتری را فراهم می کند.در این پست وبلاگ، هایدریشن را در توسعه وب تعریف می کنیم و به نحوه عملکرد آن در React نگاه می کنیم. همچنین برخی از روش‌های توصیه‌شده برای معرفی و بهینه‌سازی هایدریشن را مرور خواهیم کرد.هایدریشن دقیقا چیست؟هایدریشن فرآیند انتقال HTML ارائه شده توسط سرور به سمت کلاینت است، جایی که می تواند به یک صفحه وب کاملاً تعاملی تبدیل شود.مزیت اصلی هایدریشن این است که سرعت بارگذاری سریعتر صفحات وب را امکان پذیر می کند. رندر سمت سرور می‌تواند با پیش رندر کردن HTML پایه، به کاهش زمان بارگذاری صفحه کمک کند، اما فاقد رفتار سمت مشتری و تعامل است. این زمانی است که هایدریشن وارد می شود و عملکرد مورد نیاز سمت کلاینت را به محتوای از پیش رندر شده اضافه می کند. این کار باعث می شود که در بررسی های SEO سایت هم نمره هایی بالاتری بگیرید.هایدریشن در Reactفریمورک React به دلیل فرآیند هایدریشن سریع خود شناخته شده است. فریمورکReact از یک DOM مجازی استفاده می‌کند تا فقط قسمت‌هایی از صفحه را که باید آپدیت شود را بروز کند و بقیه صفحه را تغییر ندهد. این بدان معناست که، در حالی که هایدریشن می تواند یک عملیات طولانی باشد، DOM مجازی React، آن را سرعت می بخشد و آن را بهینه می کند.برای به دست آوردن HTML اولیه برای هایدریشن در React، ابتدا باید کامپوننت ،سمت سرور رندر شود. سپس، در سمت کلاینت، از متدReactDOM.hydrate برای اضافه کردن Event Listener ها و داده‌ها به HTML استفاده کنید. توجه کنید که طبیعتا فقط وقتی SSR داریم چنین چیزی معنا پیدا می کند.اما علت اصلی نوشتن این مقاله مشکلی است که هر از چند گاه ممکن اس در console اپلیکیشن خود ببینید. که یک warning مربوط به hydration است. که خیلی نامفهموم است ولی به عنوان برنامه نویس واقعا وقتی در console یک سایت خطا یا warning می بینم حس خوبی ندارم و واقعا روی اعصابم می رود (البته شاید من وسواس دارم 😁)برخی از خطاهایی که من برخورد کردم:Warning: Text content did not match. Server: "Pre-rendered server content" Client: "Client app content" at div.Warning: An error occurred during hydration. The server HTML was replaced with client content in div.Text content does not match server-rendered HTML.Hydration failed because the initial UI does not match what was rendered on the server.There was an error while hydrating. Because the error happened outside of a Suspense boundary, the entire root will switch to client rendering.دلیل پشت این خطاها عدم تطابق بین HTML ارائه شده توسط سرور و آنچه توسط برنامه فرانت تولید می شود، است. برای اینکه هایدرشن به درستی کار کند، HTML باید دقیقاً یکسان باشد.خیلی وقت ها اصلا برنامه نویس مرتکب اشتباهی نشده است و ذات کد نوشته شده مشکل زا است. هر چیز پویا در برنامه، ممکن است یک مقصر باشد. در اینجا یک مثال عملی از زمانی که ممکن است این اتفاق بیفتد آورده شده است:function PracticalHydrationError({ theDate }) { const formatted_date = new Date(theDate).toLocaleDateString(); return

{formatted_date}

; }در این کامپوننت، یک تاریخ به فرمت لوکال قالب‌بندی می‌شود. مشکل اینجاست که ممکن است سرور از همان فرمت استفاده نکند، و تاریخ موجود در قسمت فرانت با آنچه که توسط backend ارائه شده، مطابقت نداشته باشد. توجه کنید که اگر لوکال کاربر با سرور یکی باشد، خطا ندارد فقط کاربر که تنظیمات متفاوتی با سرور داشته باشداین خطا را می بیند و ممکن است که شما همیشه خطا نداشته باشید 😟.راه حل هااگر با useEffect آشنا هستید، ارسال یک آرایه وابستگی خالی باعث می‌شود که تابع فقط زمانی فراخوانی شود که کامپوننت برای اولین بار رندر شده است و با درنظر گرفتن یک مشخصه و true کردن آن بعد از اولین رندر می‌توان مشکل را حل کرد.از دیدگاه کاربر، این بدان معنی است که صفحه ابتدا بدون تاریخ نمایش داده می شود و پس از بارگیری برنامه به طور ناگهانی ظاهر می شود.export default function NoFirstRender({ theDate }) { const [hydrated, setHydrated] = React.useState(false); React.useEffect(() => { setHydrated(true); }, []); if (!hydrated) { return null; } const formatted_date = new Date(theDate).toLocaleDateString(); return

{formatted_date}

; }در واقع ایده ی کلی این است که یا چیزی سمت سرور برگردانده نشود یا دیتای متفاوتی سمت سرور و کلایت برگردانده شود.اما اگر برنامه نویس حرفه ای باشید می دانید که این راه حل خیلی راه جالبی نیست. اما چرا؟هدف useEffect ربطی به هایدرشن ندارد. ارسال آرایه وابستگی خالی ([]) باعث می شود تا زمانی که کامپوننت برای اولین بار mount می شود، تابع اجرا شود.اما ممکن است که یک کامپوننت بارها mount و unmount شود.برای حل این مسئله ، ما می توانیم React Context و Provider استفاده کنیم تا اطمینان حاصل کنیم که بررسی Hydration فقط یک بار انجام می شود:const HydrationContext = React.createContext(false); function HydrationProvider({ children }) { const [hydrated, setHydrated] = React.useState(false); React.useEffect(() => { setHydrated(true); }, []); return {children}; } function MyDateComponent({ theDate }) { // Retrieve the hydration state from the context const hydrated = React.useContext(HydrationContext); const date = new Date(theDate); const formatted_date = hydrated ? date.toLocaleDateString() : date.toUTCString(); return

{formatted_date}

; } export default function OnlyRerenderAfterHydration() { return ( ); }با انتقال بررسی هایدرشن به یک Provider، نیازی به فراخوانی آن هر بار که کامپوننت ما نصب می‌شود، نیست.اگر را در بالاترین سطح برنامه خود قرار دهیم، بررسی هایدرشن فقط یک بار در زمانی که برنامه واقعاً Hydrate شده است امجام می شود، نه هر بار که یک کامپوننت نصب می شود.بنابراین، اگر بارها از در برنامه خود استفاده کنید، تعداد رندرها به میزان قابل توجهی کاهش می یابد.

کالبدشکافی مشکلات و حوادث: یادگیری از شکست

Amir Mirkamali — Mon, 07 Mar 2022 11:53:06 +0330

در صنعت نرم افزار، اغلب با مقیاس های بزرگ، سیستم های پیچیده و توزیع شده کار می کنیم. سازمان ها بطور طبیعی، می خواهند که مرتباً، خدمات خود را با ویژگی های جدید ارتقا دهند و سیستم های جدیدی را به سیستم های فعلی، بیفزایند. با توجه به مقیاس و سرعت تغییر سیستم ها، حوادث و مشکلات اجتناب ناپذیر هستند. وقتی یک حادثه رخ می دهد، تمام تلاش تیم ها، بر روی یافتن مشکل و حل آن متمرکز می شود. ولی همیشه باید توجه داشته باشیم که از این حوادث باید درس بگیریم، وگرنه این مشکلات مرتب تکرار خواهند شد. در صورت عدم کنترل و یادگیری از مشکلات، حوادث می‌توانند در آینده پیچیده‌تر و بزرگتر شوند و خسارتی که به ما و کاربران ما می زنند، بیشتر شود و رضایت از سیستم را کاهش دهند.هر مشکلی، علتی دارد و اگر بتوانید جلوی تکرار این مشکل را بگیرید، قطعا نگهداری و توسعه سیستم در آینده راحت‌تر خواهد بود. صرف اینکه مشکل را حل کردید و دوباره به روند عادی بازگشتید کافی نیست، باید کار کنید که دیگر آن مشکل تکرار نشود.هزینه شکست آموزش است.کالبدشکافی مشکلات و حوادث، تا حدی در صنعت فناوری شناخته شده است. کالبدشکافی حادثه، به طور خلاصه، شامل ثبت کتبی یک حادثه، تأثیر آن، اقدامات انجام شده برای کاهش یا حل آن، علت(های) اصلی و اقدامات بعدی برای جلوگیری از تکرار حادثه است.در این مقاله، معیارهایی را برای تصمیم گیری، در مورد زمان انجام این کالبدشکافی، برخی از بهترین شیوه ها در این مورد و توصیه هایی در مورد نحوه پرورش این فرهنگ ارایه خواهیم کرد.فلسفه کالبدشکافی حوادثاهداف اولیه نوشتن کالبدشکافی حادثه، این است که اطمینان حاصل شود که حادثه مستند شده است، همه علل اصلی مؤثر به خوبی درک شده اند و به ویژه، اقدامات پیشگیرانه مؤثر برای کاهش احتمال تکرار حادثه انجام می شود.کالبدشکافی حادثه، باید پس از هر رویداد نامطلوب قابل توجهی انجام شود. به این مقوله نباید مثل یک مجازات نگاه کرد، بلکه یک فرصت یادگیری برای کل سیستم است. فرآیند کالبدشکافی حادثه، طبعاً زمان بر است و برای سیستم هزینه خواهد داشت پس باید در انتخاب زمان صحیح برای این کار دقت کافی را به خرج دهید. اما دلایل عمومی برای راه اندازی این فرآیند عبارتند از:خرابی سیستم وقتی که برای کاربران قابل لمس باشد (فراتر از یک آستانه خاص)از دست دادن داده ها از هر نوعکارشناسان در حال خدمت مجبور به دخالت مستقیم در روندهای سیستم شوند.زمان حل مشکل بالاتر از یک آستانه باشدنقص در سیستم های نظارتی (که معمولاً به کشف دستی حادثه دلالت دارد)تعیین معیارهای درست بسیار مهم است تا همه بدانند چه زمانی این فرآیند را باید انجام دهند. البته در برخی موارد، برای تعیین سطح اهمیت مشکل، باید شهودی عمل کنید یعنی به حس خود مراجعه کنید و مشکل پیش آمده را کالبد شکافی کنید.بی گناهی افراد تیم، یکی از اصول این فرآیند است، توجه کنید که نباید به همدیگر اتهام بزنید و باید بر شناسایی علل مؤثر حادثه تمرکز کنید بدون اینکه فرد یا تیمی را برای رفتار بد یا نامناسب متهم کنید. یک کالبد شکافی بی‌عیب، فرض می‌کند که هرکسی که در یک حادثه نقشی داشته است، نیت خوبی داشته و با اطلاعاتی که در اختیار داشته، کار درستی انجام داده است. اگر فرهنگ گرفتن انگشت اتهام به افراد تیم و ایجاد شرمساری برای افراد یا تیم ها، به دلیل انجام کار «نادرست»، حاکم شود، کارشناسان از ترس مجازات، مسائل را آشکار نمی کنند یا حتی برای دوستان خود پوشش ایجاد خواهند کرد.باید محیطی را پرورش دهید که در آن هر "اشتباهی" فرصتی برای تقویت سیستم تلقی شود. وقتی سیستم شما بجای سرزنش فرد خطا کار، به بررسی دلایل سیستماتیک خطاها بپردازد، می توان برنامه های پیشگیری موثری را برای عدم تکرار مشکلات در نظر گرفت. شما نمی‌توانید افراد را «تعمیر» کنید، اما می‌توانید سیستم‌ها و فرآیندها را برای حمایت بهتر از کارشناسان، اصلاح کنید و به آنها کمک کنید در آینده تصمیم های درست تری بگیرند و نسخه های کم مشکل تری را عرضه کنند.هنگامی که اتفاق ناگوار در سیستم اتفاق می افتد، کالبدشکافی حادثه، باید توسط کارشناسان به‌عنوان فرصتی نه تنها برای رفع یک ضعف، بلکه برای انعطاف‌پذیرتر کردن کل سیستم تلقی شود و در پایان باید نشان دهد که کجا و چگونه خدمات را می‌توان بهبود بخشید. همکاری و به اشتراک گذاری دانش همکاری در تیم یک گوهر با ارزش است در فرآیند کالبدشکافی این همکاری بسیار بسیار مهم است. در واقع فرآیند اصلی کالبدشکافی، شامل همکاری و اشتراک دانش در هر مرحله است. صرف نظر از هر ابزار خاص یا سیستمی که برای اینکار استفاده می کنید، در آن ابزار به دنبال ویژگی های کلیدی زیر باشید:امکان همکاری Real-time در تیم، که جمع آوری سریع داده ها و ایده ها را فراهم می کند. امکان درج اظهار نظر/ حاشیه نویسی بازاعلان های ایمیلنوشتن مستندات نیز مستلزم بررسی و انتشار رسمی است. در عمل، تیم ها اولین پیش نویس را به صورت داخلی به اشتراک می گذارند و کارشناسان ارشد پس ارزیابی کامل بودن پیش نویس، آن را منتشر خواهند کرد. معیارهای بررسی ممکن است شامل موارد زیر باشد:آیا داده های کلیدی حادثه برای آیندگان جمع آوری شد؟آیا ارزیابی تاثیرات کامل است؟آیا علت اصلی به اندازه کافی عمیق بود؟آیا برنامه اقدام مناسب است و رفع اشکال در اولویت مناسب است؟آیا ما نتیجه را با ذینفعان مربوطه در میان گذاشتیم؟هنگامی که بررسی اولیه کامل شد، مستندات به طور گسترده‌تری به اشتراک گذاشته می‌شود، معمولاً برای کل تیم. هدف ما این است که مستندات تهیه شده را با گسترده ترین مخاطبان ممکن به اشتراک بگذاریم که همه از دانش یا درس های داده شده بهره مند شوند. البته هر شرکتی سیاست های خاص خودش را در انتشار اطلاعات دارد.بسیار مهم است که هیچ موردی را جا نیندازید. جلسات منظم برگزار کنید و با ابزار مختلف تیم را تشویق کنید که در مورد حادثه بحث و گفتگو کنند و راهکار ارایه دهند و پس از یافتن راهکار مناسب، حتما مطالب را داکیومنت و ثبت کنید. فرهنگ کالبدشکافی حادثهاگر بتوانید یک فرهنگ سازمانی برای این فرآیند ایجاد کنید، کار شما بسیار ساده تر خواهد شد. البته چنین کاری مستلزم تزکیه و تقویت مستمر رفتار اعضای تیم است. پیشنهاد می شود که این فرهنگ مشترک، از طریق مشارکت فعال مدیریت ارشد در فرآیند بررسی و همکاری، تقویت شود. مدیریت تیم نقش بسیار مهمی در ایجاد این فرهنگ دارد. برخی از فعالیت های نمونه عبارتند از:انتشار یکی از فرآیند های انجام شده در خلال ماه برای همه در یک خبرنامه ماهانه، یک پس از مرگ جالب و خوب نوشته شده با کل سازمان به اشتراک گذاشته می شود.تشکیل یک گروه خاصاین گروه، بهترین شیوه ها و راهکارهای را برای شرکت ترسیم می کند.جلسه های مطالعه مشکلات و حوادث قبلیاز برخی خوادث ممکن است سالها گذشته باشد و خواندن آنها حتما می تواند موثر و برای اعضای جدید آموزنده باشد.یکی از بزرگترین چالش ها، جا انداختن این فرآیند به یک سازمان این است. معمولا کسانی در مجموعه شما وجود دارند که ممکن است اهمیت این فرآیند و نتیجه آن را زیرسوال ببرند. استراتژی‌های زیر می‌توانند به شما کمک کنند تا به این چالش غلبه کنید:یک دوره آزمایشی با چندین نمونه کامل و موفق ممکن است به اثبات ارزش فرآیند کمک کند. سعی کنید که در سازمان خود یک نمونه موفق را اجرا کنید تا اعتماد مدیران بالاتر را جلب کنید.برای کسانی که درست و دقیق در فرآیند شرکت کرده اند، پاداش تعیین کنید. پاداش ها را واضع و علنی بدهید تا بقیه نیز تشویق شوند.در مورد اهمیت و نقش این فرآیند صحبت کنید و همه را تشویق کنید.خلاصهاگر بتوانید یک فرهنگ درست در سازمان خود خلق کنید که بعد از اینکه یک مشکل بوجود می آید و تیم با موفقیت آن را پشت سر می گذارد، اعضای تیم یکبار دور هم جمع شوند و مشکل را دوباره بررسی کنید و راهکارهای عدم تکرار آن را بررسی و مکتوب کنند، مطمئن باشید که با گذشت زمان حتما سیستم بهتری خواهید داشت و در پایان این نکته فراموش نشود که در جلسات کالبدشکافی، همدیگر را متهم نکنید. در انتخاب کلمات دقت داشته باشید، طعنه نزنید و تمام تلاشتان این باشد که از مشکل پیش آمده، یادبگیرید و جلوی تکرار آن را بگیرید.به یاد داشته باشید که تجربیاتی که در محیط عملیاتی بدست می آید بسیار با ارزش هستند و معمولا در محیط اکادمیک بدست نمی آیند. مشکلات و راهکارها را حتما داکیومنت کنید تا از تکرار آنها جلوگیری کنید.

فرم های لاگین: رایج ترین مشکلات و راه حل های آن

Amir Mirkamali — Sat, 11 Sep 2021 17:36:27 +0430

قبل از خواندن مقاله، لازم است که پیشگفتار را بخوانید تا تصمیم بگیرید که آیا مطلب زیر برای سایت یا اپلیکیشن شما مفید خواهد بود یا نه!پیشگفتارتوجه کنید که اگر یک سایت خیلی مهم و امنیتی دارید شاید برخی موارد ذکر شده در این مقاله به درد شما نخورد. این نکته خیلی مهم است که تقریبا قانونی کلی در این زمینه وجود ندارد و شما براساس نیاز و شرایط سایت خود، جریان لاگین و پیام ها را تعیین می کنید.ولی به نظر من مهمترین مساله در UX یک اپلیکیشن یا سایت این است که کاربر بتواند از سرویس شما به درستی استفاده کند و اپ یا سایت شما را به دلایل واهی ترک نکند.تجربه به من نشان داده است که کاربران خیلی کم حوصله تر از آن هستند که شما فکر می کنید و بسیاری از ریزش ها در همین فرم های لاگین اتفاق می افتد. هر چه لاگین سریعتر و روان تر باشد امکان ادامه روند توسط کاربر (مخصولا در فروشگاه ها) بیشتر است.قبل‌ها بر این عقیده بودم که امنیت یک نرم افزار مهم‌ترین مساله‌ای است که در نرم افزار با آن مواجه هستیم و فکر می‌کردم که همه چیز باید فدای این مساله شود. برای همین همیشه مخالف نمایش پیام های خطای دقیق، به کاربران بودم با این استدلال که این خطاها، راه‌هایی برای حمله کنندگان به سایت ها و اپلیکیشن‌ها فراهم می‌کند.اما به مرور متوجه شدم که یک راه حل کلی، برای یک مساله وجود ندارد و در اپلیکیشن‌های متفاوت، تعریف متفاوتی از مساله امنیت وجود دارد. ارایه راهکار و هدایت کاربر به سمت و سوی صحیح، یکی از مهمترین مسایلی است که کاربر را در سایت نگه می‌دارد و این یکی از مهمترین مسایلی است که برای یک کسب و کار مهم است.مقاله زیر یک جمع بندی از مقاله‌ای است که خواندم و امیدوارم که برای شما هم مفید باشد.مسایل و مشکلات فرم های لاگینبرای بسیاری از ما، ورود به سایت ها یا برنامه ها، بخشی از برنامه روزانه است. احتمال اینکه در یک خرید یا بازدید از سایت به صفحه های لاگین بربخورید، بسیار زیاد است.مشکل زمانی پیش می‌آید که رمز عبور، نام کاربری یا آدرس ایمیلی که با آن ثبت نام کرده‌ایم را فراموش می‌کنیم، یا حتی ممکن است ندانیم که آیا اصلا ثبت‌نام کرده‌ایم یا نه؟تجزیه و تحلیل دقیق یک سایت تجارت الکترونیک، نشان داده است که 45 درصد از مشتریان چندین ثبت نام در سیستم داشتند، 160 هزار نفر هر روز، رمز عبور خود را درخواست می‌کردند و 75 درصد از این افراد، هرگز خریدی را که پس از درخواست رمز عبور خود شروع کرده بودند تکمیل نکردند.شاید باور اعداد و ارقام بالا سخت باشد ولی این اعداد به وضوح نشان می‌دهد که تجربه ورود به سیستم، یک مساله بسیار مهم است. طراحان همیشه باید تلاش کنند تا تجربه‌ای روان و راحت ایجاد کنند و البته برنامه نویسان Back-end که بتوانند با رعایت مسایل امنیتی دست Front-end Developer را باز بگذارند تا UX طراحی شده را اجرا کند.در اینجا چند نکته وجود دارد که باید برای ایجاد تجربه کاربری خوب، باید روی آنها تمرکز کنید:۱- در مورد خطاها با کاربران روراست باشیدوقتی کاربران با مشکلی در ورود به سیستم روبرو می‌شوند، می‌خواهند بدانند چه چیزی باعث این مشکل شده است. از دادن پیام‌های کلی و به اصلاح گرد خودداری کنید.ترکیب اشتباه نام کاربری و گذرواژه می تواند منجر به چندین تلاش قبل از ورود موفقیت آمیز به سیستم شود، یا باعث ناامیدی و خروج کاربر از سایت شود.پاسخ های عمومی (مانند "ایمیل یا رمز عبور شما مطابقت ندارد") بازخورد معنی‌داری به کاربران شما ارائه نمی‌دهد و به آنها اجازه نمی‌دهد مشکل خود را برطرف کنند. کاربرانی که وارد سیستم نشده‌اند، "یکی از این دو مورد اشتباه است اما من به شما نمی گویم کدامیک" را می خوانند، و این میزان تبدیل و تعامل را کاهش می‌دهد. خلاصه‌ی مطلب این که کاربران سایت شما را می بندند و می روند!شما باید به کاربر کمک کنید تا کار ورود به سیستم را درست و کامل انجام دهد. در پاسخ باید دقیق توضیح داده شود که کدام بخش مساله دارد: گذرواژه یا آدرس ایمیل.یک مثال جالب اینکه در MailChimp، استرس فراموش کردن نام کاربری/رمز عبور ترکیبی کاهش داده شده است. بدین صورت که اگر نام کاربری وجود ندارد، قبل از اینکه شروع به وارد کردن رمز عبور کنید، به شما می گوید که شناسه‌ای که وارد کردید اصلا وجود ندارد.سایت به صورت اتوماتیک مشکل را تشخیص داده و پیوندی ارائه می‌دهد که راه حل مشکل کاربر است و به کاربر اجازه می‌دهد آن را برطرف کند.سرویس پرسش و پاسخ Quora رویکرد مشابهی را در پیش گرفته است. فرم ورود به Quora به شما می گوید که هیچ حسابی با آدرس ایمیلی که وارد کرده‌اید مرتبط نیست و به شما این امکان را می دهد که یک حساب جدید درست در آنجا ایجاد کنید.اما این تکنیک یک نقطه ضعف بزرگ نیز دارد: ممکن است به بعضی ها اجازه دهد که بدانند که یک ایمیل، شخص، نام خاص در یک سایت یا برنامه ثبت شده است. امنیت و حریم خصوصی داده ها بخش مهمی از طراحی UX است به همین دلیل این راه حل برای بانکداری آنلاین (دلایل امنیتی) یا خدماتی که ممکن است کاربران نگران وضعیت عضویت خود باشند (دلایل حفظ حریم خصوصی) توصیه نمی‌شود.۲- به کاربران یادآوری کنید که رمز عبور خود را تغییر داده‌اند.کاربران می‌توانند آنقدر به تایپ گذرواژه قدیمی خود عادت کنند که فراموش کنند آن را تغییر داده‌اند و وقتی پیام خطا "رمز شما اشتباه است" را مشاهده می‌کنند، به سادگی متقاعد شوند که رمز عبور را اشتباه وارد کردهاند.آنچه کاربران در این مورد نیاز دارند یادآوری این است که رمز عبور آنها تغییر کرده است. به جای این که به کاربران پیغام خطای "گذرواژه شما اشتباه است" بدهید، به آنها بگویید چه مدت پیش رمز عبور خود را تغییر داده اند. این پیام فقط زمانی ظاهر می شود که کاربران گذرواژه قدیمی خود را تایپ کنند. اگر کاربران رمز عبور را اشتباه وارد کرده اند، سیستم باید پیغام خطای معمولی "رمز عبور اشتباه" را نمایش دهد.۳- یک مسیر خوب و درست برای وقتی که کاربر رمز عبورش را فراموش کرده، طراحی کنید.اکثر کاربران رمز عبور خود را فراموش می کنند. بنابراین بسیار مهم است که این وضعیت به خوبی توسط فرایند ورود، مدیریت شود. برای بازنشانی گذرواژه، فرم های ورود باید دارای پیوند "رمز عبور فراموش شده" باشند.این پیوند را همیشه نشان بدهید و این طور نباشد که فقط در شرایط خاص نمایش داده شود.در صورتی که آدرس ایمیل خود را وارد کرده اند و سپس از ویژگی رمز فراموش شده استفاده کرده اند، مجدداً مجبور نشوید آدرس ایمیل خود را در صفحه رمز فراموش شده وارد کنید.رمز عبور فعلی یا موقت را از طریق ایمیل ارسال نکنید (دلایل امنیتی)کار درست این است که پیوند بازنشانی رمز عبور را در آدرس ایمیل ثبت شده ارسال کنید. همچنین، مطمئن شوید ایمیل بازنشانی رمز عبور، در اسرع وقت ارسال می شود. هنگامی که دریافت پیوند بازنشانی گذرواژه چند دقیقه (یا حتی چند ساعت) طول می کشد، ممکن است کاربران از این رفتار به راحتی ناراحت شوند.همین مورد در مورد گذرواژه های یکبار مصرفی که با اس ام اس ارسال می شود هم صادق است. اگر تاخیری در ارسال پیام وجود داشته باشد، کاربر سایت شما را ترک می کند.۴- قبل از قفل شدن حساب کاربری به کاربر هشدار بدهیدبرای جلوگیری از Brute Force، حساب های کاربری اغلب پس از تعدادی تلاش ناموفق برای ورود، به طور موقت قفل می شوند. البته این یک اقدام امنیتی ضروری است، اما قبل از قفل شدن حساب کاربری، به کاربران هشدار دهید.برای مثال MailChimp پس از سومین تلاش به کاربران هشدار می دهد که پس از 9 بار تلاش ناموفق دیگر، حساب آنها به مدت 30 دقیقه قفل می شود.

توسعه دهندگان انعطاف ناپذیر و نقش سمی آنها در تیم های نرم افزاری

Amir Mirkamali — Fri, 03 Sep 2021 14:33:22 +0430

نگرش، در همکاری درون تیمی، بسیار مهم است. بدترین کاری که شما می توانید انجام دهید، استخدام یک فرد خودخواه یا لجباز است که هر چقدر هم که محیط شما سالم باشد، با گذشت زمان، یک محیط سمی برای تیم شما ایجاد خواهد کرد.آنچه به تجربه در این سالها آموختم، این بوده است که این نوع نگرش، به قدری سمی است که هم تیمی ها را به حالت خستگی مداوم می برد و این گونه افراد، هیچ گونه رشدی برای تیم ایجاد نمی کنند و مهمتر از همه، تیم به جای انجام دادن کارهای اصلی، زمان زیادی را برای مبارزه با آنها تلف می کند و به مرور زمان، کل مجموعه ضرر خواهد کرد.توسعه دهندگان سرسخت مانند زامبی هایی هستند که انرژی شما را از بین می برند و تمام انرژی شما را می مکند، در تعامل با آنها، مدام احساس خستگی می کنید مضاف بر اینکه بهره وری شما نیز پایین می آید.دلیل اصلی این اتفاق، این است که در اکثر اوقات، آنها فکر می کنند حق با آنهاست و همین نگرش، آنها را بسیار لجباز می کند. افردی که دارای ذهن باز هستند، معمولا با آغوش باز توصیه ها را می پذیرند و در مسیر کاری خود با سرعت بیشتری می توانند پیشرفت کنند و طبیعتا برای این افراد دقیقا برعکس است!فرد لجباز، همیشه حس می کند که به او حمله کرده اید! و می خواهد از خود دفاع کند و همواره فکر می کن که این اظهارنظر شما، یک توهین به کار و تفکر اوست.این بحث و جدل مداوم و جلسات رفت و برگشتی، تمام انرژی شما را می مکد و باعث می شود که در برابر طرف مقابل، احساس استیصال کنید. ?اما توسعه دهندگان خودخواه چه کسانی هستند؟ در واقع توسعه دهندگان سرسخت در حال طی طریق برای تبدیل شدن به توسعه دهندگان خودخواه هستند. توسعه دهندگان خودخواه، در سطح دیگری از توسعه دهندگان سرسخت قرار دارند. توسعه دهندگان خودخواه، در واقع مربیان توسعه دهندگان سرسخت هستند و به آنها کمک می کنند راه خود را به سمت خودخواهی خود باز کنند. توسعه دهندگان سرسخت توسعه دهندگان لجباز و انعطاف ناپذیری هستند که شامل گذر زمان شده اند?اگر ما بتوانیم یک چک لیست در مورد ویژگی های توسعه دهندگان خودخواه و نحوه فکر آنها داشته باشیم، این موارد را شامل خواهد شد:لجبازینگرش متفاوت و ثابت نسبت به همه چیز!من همه چیز را می دانم!من از شما برترم!من قسمت زیادی از این نرم افزار را ایجاد کردم و بنابراین شما هیچ چیز نیستید!چیزی که من توسعه داده ام خیلی خوب است و نیازی به توسعه و تغییر ندارد!این کد من است!و صدها مورد دیگر ?‍♀️در حالی که برنامه نویسان سرسخت می توانند مقصود شما را بفهمند، این گونه از توسعه دهندگان به دلیل توهم ذهنیت برتر و زندگی با این تفکر (طی سالیان متمادی) نمی خواهند چیزی را درک کنند. آنها فکر می کنند که بالاتر از همه هستند و قابل دسترس توسط دیگران نیستند (فاصله دیگران با آنها زیاد است) این تفکر و رفتار باعث می شود که شما در هنگام بحث و تبادل نظر با آنها، مرتب به فکر کوبیدن سر خود به دیوار باشید!آنها بسیاری از استدلال ها را در خلق الساعه ایجاد می کنند تا احساس کنند که شما چیزی نمی دانید. یعنی موقعی که آن کار را انجام داده اند (برنامه را نوشته اند) استدلال خاصی برای آن نداشته اند اما به محض اینکه پیشنهاد جدید یا انتقادی در مورد آن می شنوند، شروع به تولید و ساختن انواع و اقسام استدلال ها، برای توجیه آن کار می کنند (برای اینکه کاری که شما می خواهید را انجام ندهند) در ذهن آنها، پیروزی همیشه مهم است. چنین توسعه دهندگانی اغلب تنها بوده و به عنوان یک ارتش یک نفره کار می کنند، مطالب زیادی در مورد همکاری یا همدلی نمی دانند و دوست دارند که به صورت یک جعبه سیاه کار کنند و کسی از داخل کار آنها اصلاعاتی نداشته باشد و از آنها چیزی نپرسد و پیشنهادی ندهد. فقط تسک های مربوطه را انجام دهند و خارج از دایره وظایف نیز کاری انجام نمی دهند. انتقاد از آنها هم طبیعتا ممنوع است. ?‍♂️کار در یک تیم به ذهنیت تیمی نیاز دارد. مسایل در یک تیم نباید شخصی شود و تیم همیشه باید در معرض انتقاد سازنده باشد. برنامه نویسان سرسخت و خودخواه، همه چیز را شخصی می کنند! من معتقدم این افراد محیط را سمی می کنند و این محیط سمی، برای هیچ تیمی مناسب نیست و باعث کندی حرکت تیم خواهد شد.مهمترین جایی که می توان جلوی این افراد را گرفت، هنگام استخدام است. یک کار قابل انجام این است که چند سناریو در مصاحبه از آنها بخواهید که مبتنی بر همکاری تیمی است. مهارتهای همکاری فرد، غیر از مهارتهای فنی وی مهم است. بنده به تجربه دریافته ام که اگر فردی روحیه کار تیمی نداشته باشد، حتی با قرار گرفتن در منعطف ترین تیم ها نیز تغییر نخواهد کرد. این افراد باید از ابتدا شناسایی شوند و اصلا جذب نشوند!آیا داستان خوبی درباره مکالمه با یک توسعه دهنده خودخواه یا سرسخت دارید که شما را به مرز خودکشی رسانده باشد؟?

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

Amir Mirkamali — Fri, 03 Sep 2021 14:20:46 +0430

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

طرز برخورد با افرادی که به شما کم محلی و یا شما را تحقیر می کنند

Amir Mirkamali — Fri, 03 Sep 2021 14:08:58 +0430

واکنش نشان دادن در مقابل افرادی که شما را تحقیر و خوار کرده و ارزش هـایتـان را زیر سؤال می برند، قدری دشوار و دردناک است. گاهی اوقات زخم هایی که اینگونه افراد به شما وارد می آورند، ممکن است تا ابد باقی بمانند.مـن خــودم به شخصه زمانیکه به گذشته بر می گردم افراد بســیار زیادی را به خاطر می آورم که در برهه های مختلف زنـدگی مرا تحقیر می کردند و ارزش ها و توانایی هایم را دسـت کـم مــی گرفتند.مطمئنـــم که همه شما تجربه ای مشـابه من داشته اید، شاید کمتر کسی باشد که در طول زنـدگی خود با افراد این چنینی برخورد نکرده باشد. بهترین تکــنیک این است که یاد بگیریم به جای اینکه برخورد تند از خود نشان بدهیم، با آنها مدارا کنیم. شخصیت این افراد دچار نقضان می باشد کمبودهایی در زندگیشان وجود دارد که برای درمان آنها حتماً باید به روانشناس مراجعه کنند و شاید هیچ گاه اصلاح نشوند اما با صبر و حوصله و رعایت برخی موارد زیر می توان نتیجه های خوبی گرفت.باید توجه داشته باشید که افرادی که شما را تحقیر می کنند و قصد آسیب رساندن به شما را دارند، در درجه اول باید خودشان را بیازارند تا بتوانند شما را آزرده کنند.باید بدانید که یک انسان کامروا، موفق، و با اعتماد به نفس هیچ نیازی به تحقیر دیگران ندارد. شاید این افراد از دیگران انتقادهای سازنده ای کنند، اما هیچ گاه آنها را تحقیر نمی کنند. برخی از افراد به طور کلی نظر منفی نسبت به دیگران دارند چون:– به دلیل کمبودهایی که احساس می کنند دوست دارند خودشان را قدرتمند تر از سایرین جلوه بدهند تا به این طریق بر تزلزل شخصیتی خود غلبه کنند.– قبلاً کسی آنها را آزرده ساخته و چون توانایی مقابله با آن را نداشتند، با تحقیر دیگران سعی می کنند از موقعیت فعلی خود دفاع کند.افرادی که به شدت شما را تحقیر می کنند با این کار فقط ناراحتی، عدم موفقیت، و بی هدفی خود را در زندگی به نمایش می گذارند و این مشکل آنهاست نه شما. دانستن این مطلب به شما کمک می کند که راحت تر بتوانید در کنار آنها به زندگی عادی خود ادامه دهید و حرف هایشان را نشنیده بگیرید. اگر بدانید که مشکل از طرف مقابل است نه شما، می توانید منطقی با مسائل برخورد کنید و از حرف ها و کنایه های آنها شما را آزرده نخواهد کرد.شاید فردی که دارای چنین خصوصیاتی است یکی از نزدیکان شما باشد و برایتان سخت باشد که بخواهید از نظر عاطفی خودتان را از او جدا کنید. هیچ نیازی به این کار نیست، فقط سعی کنید در بحث هایی که او راه می اندازد، شرکت نکرده و خودتان را کنار بکشید. قصد او این است که کاری کند تا شما احساس بدی نسبت به خودتان پیدا کنید. این وظیفه شماست که به آنها اجازه انجام چنین کاری را ندهید. برای بدست آوردن اطلاعات بیشتر در مورد چگونگی برخورد با افراد منفی نگر به قسمت: “طرز برخورد با افراد منفی گرا” مراجعه کنید.توضیحات و نکاتی در مورد افرادی که شما را تحقیر می کنند:زمانیکه اینگونه افراد به شما حرفی می زنند، در پاسخ به آنها، جواب های بی شماری به ذهن شما خطور می کند. اگر چنین کاری را انجام دهید، در واقع خودتان را با آن فرد هم شان ساخته اید و این دقیقاً همان چیزی است که آنها انتظارش را می کشند. آنها می خواهند شما را عصبانی کنند تا برخورد شدیدی از خود نشان دهید، آنها میخواهند شما احساس بدی نسبت به خودتان پیدا کنید و قصدشان تنها آزار دادن و آسیب رساندن است. شما با جواب دادن به آنها در حقیقت وارد بازی ساختگی شان میشوید، و در نهایت خودتان را آزار داده اید. ممکن است بعداً به خاطر حرف هایی که در عصبانیت از دهانتان خارج شده پشیمان شوید. خوب در زمان بروز چنین حالتی چه کاری می توان انجام داد؟ بهتر است یکی از موارد زیر را امتحان کنید:زمانیکه احساس می کنید فردی با حالت تهاجمی با شما برخورد می کند می توانید بگویید: “ازت ممنونم اما فکر می کنم بهتر است توصیه هایت را برای خودت نگه داری”و یا: “خیلی سخاوتمندی ولی من نیازی به توصیه های تو ندارم”همه این مسائل به دلیل خشم و نفرتی که در آنها وجود دارد، درست می شود و شما هم مجبور نیستید که بار مسئولیت زندگی آنها را به دوش بکشید. شاید آنها بخواهند که از خشم و نفرت خود به شما سهمی بدهند، اما این “هدیه” ای است که شما واقعاً نیازی به آن ندارید.اگر به توصیه های آنها گوش کنید و هدیه های مسمومشان را قبول کنید، با این کار خشم و عصبانیت آنها را به به درون خود راه داده اید. به خودتان اجازه انجام چنین کاری را ندهید. شما هیچ نیازی به این هدایا ندارید، از کنار آنها عبور کنید.از پیشنهادت ممنونمیکی دیگر از واکنش های مناسبی که در مقابل این افراد می توانید از خود بروز دهید این است که به آنها بگویید: “از پیشنهادت ممنونم” و بعد هم به ادامه کار خود بپردازید. با بیان این عبارت شما در حقیقت به بحث پایان می دهید. آنها منتظر هستند که شما از خود عکس العمل نشان دهید و زمانیکه این کار را انجام نمی دهید، دیگر چیزی برای گفتن نخواهند داشت.ممنونم، شاید حق با تو باشه“بایرن کیتی” در کتاب خود با عنوان: “عشقت را می خواهم – آیا حقیقت دارد؟” معتقد است که بهترین واکنش در مقابل این افراد: “ممنوم، شاید حق با تو باشه” است. او اظهار می دارد زمانیکه نظرات دیگران سبب آزرده ساختن شما می شو،د باید نگاهی عمقی به درون خود داشته باشید و ببنید دلیل اصلی این رنجش خاطرها چیست. با این کار هم عکس العمل شدید نشان نداده اید، هم بر روی خود دقیق تر شده اید.دیگران تا زمانیکه شما به آنها اجازه ندهید، نمی توانند شما را بیازارند. در برخی مواقع بهتر است نگاهی به طرز برخورد خود با طرف مقابل داشته باشید و ببینید شما چه کاری انجام داده اید که او به خودش اجازه داده تا یک چنین پیشنهاداتی نسبت به شما ارائه دهد. آیا توانایی تغییر شرایط را دارید؟ آیا به واقع عقاید او صحت دارند؟باید ببینید که چرا این اظهار نظر خاص باعث رنجش شما می شود. عکس العمل های شما، حرف های زیادی در مورد شخصیتتان می زند. در اینجا همه چیز مربوط به شماست و نه شخص مقابل.اجازه دهید بداند که چه احساسی داریداگر به فکر تلافی کردن باشید، خودتان را بی ارزش می کنید. باید خیلی رو راست به او بگویید که نظرش شما را آزرده ساخته. البته باید این کار را در نهایت آرامش انجام دهید، به عنوان مثال: “زمانیکه به نظریات من بی توجهی می کنی و آنها را نمیپذیری، واقعاً ناراحت می شوم.” فقط به آرامی بیان کنید و منتظر واکنش آنها بشوید. بهتر است این کار را زمانی انجام دهید که تک به تک با فرد مقابل تنها می شوید، این امکان وجود دارد که آنها خودشان هم متوجه نباشند که در حال آزار و اذیت شما هستند.اگر چنین بحثی در محیط کار پیش آمد، می توانید ادامه بحث را به زمان دیگری موکول کنید، به عنوان مثال اگر یکی از همکارانتان به شما گفت: “من احساس می کنم تو نسبت به مسائل مختلف بیش از اندازه حساس هستی” به او بگویید: “ترجیح می دهم روی مسائل کاری تمرکز کنیم” و یا “الآن مسائل مهمتری برای انجام دادن وجود دارد، بهتر است به مسائل کاری توجه کنیم و موارد شخصی را بگذاریم برای بعد”با این کار، آنها را متوجه می کنید که هم از نظرشان خوشتان نیامده و هم کاملاً حرفه ای با آنها برخورد کرده اید.سایر نکاتی که در این زمینه باید به خاطر داشته باشید به شرح زیر می باشد:شما نیاز به تایید دیگران نداریدگاهی اوقات نظر دیگران به این دلیل شما را آزرده می سازد چرا که از آنها انتظار تایید ۱۰۰% داشته اید، اما نظر آنها بر خلاف انتظار شما از آب در می آید. شاید پیشنهاد آنها زیاد هم بد نباشد، اما در نظر شما بد جلوه کند، به عنوان مثال اگر سرپرست بخش به شما بگوید: “کارت واقعاً عالی بود، اما آیا میتوانی پاراگراف آخر را اصلاح کنی تا کارت قوی تر شود؟” ممکن است ناراحت شوید، و به این دلیل که توقع شنیدن چنین اظهار نظری را نداشتید، قسمت اول آنرا هم نمی شنوید، و فقط متوجه بخش انتقادی آن می شوید.اگر این نوع اظهار نظرها را به عنوان نوعی توهین و تحقیر در نظر نگیرید، آنوقت میتوانید این نظریه را به عنوان فرصتی برای پیشبرد توانایی های خود به کار بندید.راهی سریع برای ایجاد عزت نفس – به دنبال تایید گرفتن از دیگران نباشیدآیا آنها از داستانهای ذهنی شما با خبر هستند؟در برخی شرایط، ممکن است نظریات دیگران در ذهن شما به منزله نوعی اهانت به شمار آید، درصورتیکه طرف مقابل به هیچ وجه قصد انجام چنین کاری را ندارد. این امر به دلیل تفکرات ذهنی شما و یا به دلیل داستان های ذهنی که برای خودتان ساخته اید، بوجود می آید، به همین دلیل چیزی را می بینید که وجود خارجی ندارد و تنها زاییده خیال و اوهام ذهنیتان است.در اینجا برایتان مثالی می آوریم؛ فرض کنید شخصی برای شما هدیه ای آورده. اگر شما اعتقاد داشته باشید که او قصد آسیب رساندن به شما را داشته، ممکن است با خودتان فکر کنید:”او می خواهد از راههای مسالمت آمیز وارد شده و از خلق خوش من سوء استفاده کند.” اما حقیقت چیز دیگری است و او تنها قصد دارد که به شما نشان دهد تا چه حد برایش ارزش و اهمیت دارید. در یک چنین شرایطی باید از خودتان سؤال کنید که آیا واقعاً همه چیز را آنطور که هست می بینید و یا می شنوید؟ (هیچ چیز معنای حاصی ندارد تا زمانیکه شما به آن معنا ببخشید) و یا اینکه داستان ذهنی خودتان را وارد کار می کنید.داستان زندگی شما چیست؟ آیا باید از آن گذشت؟آیا منعکس کننده اعتقادات شماست؟باید توجه داشته باشید که اگر خودتان احساس می کنید که فرد دوست داشتنی نیستید، آنوقت این حس به دیگران هم منتقل شده و آنها نیز تصور می کنند که نمیتوانند شما را دوست داشته باشند. اگر تصور کنید که فقط استحقاق اهانت و تحقیر را دارید، آنگاه چیزی جز این هم عایدتان نخواهد شد. اگر یک چنین تصوری دارید شاید نوبت به آن رسیده باشد که نگاه عمیق تری به درون خود انداخته و اعتقادات خود را زیر سؤال ببرید.انعکاس دادن – کلید درک شخصینسبت به تحقیرهای زیرکانه هشیار باشیدزمانیکه صبر می کنید و به پیغام هایی که به طور روزانه دریافت می کنید می اندیشید، به این نتیجه می رسید که خیلی بیشتر از آن چیزی که تصور می کرده اید در معرض انتقاد و اهانت قرار گرفته اید. دلیلش هم این است که دنیا پر است از انسان هایی که قصد تحقیر دیگران را دارند. هر جایی که می روید، به هر کجا که نگاه می کنید، هر چیزی که در روزنامه می خوانید و یا در تلویزیون تماشا می کنید، و حتی تبلیغاتی که مشاهده می کنید، همه و همه قصد دارند به شما بگویند که تا زمانیکه از محصولات آنها استفاده نکنید، طرز خاصی لباس نپوشید، مطالعات خاصی نداشته باشید، طرز خاصی راه نروید، به اندازه کافی خوب نیستید. آنها به طور ماهرانه ای عزت نفس و ارزش شخصی شما را زیر سؤال می برند.هیچ کس دوست ندارد مورد انتقاد قرار بگیرد؛ به همین دلیل اگر می خواهید سالم زندگی کنید و از عزت نفس برخوردار باشید، باید این پیغام های منفی که از سایرین در مورد شخصیتتان می شنوید را نادیده بگیرید.نگاهی اجمالی به شیوه های برخورد با افرادی که شما را تحقیر می کنندزمانیکه در معاشرت با افرادی قرار می گیرید که شما را خوار می کنند، به یاد داشته باشید:۱- با تحقیر کردن متقابل، کارشان را تلافی نکنید.۲- طرز برخوردشان چیزهای زیادی در مورد آنها به شما می گوید، به راحتی می توانید درک کنید که دلیل همه این کارها، خشم و نفرتی است که وجودشان را فراگرفته و خودشان باید با آن کنار بیایند نه شما.۳- آیا می توانید از میان نظریات آنها برای خود یک “هدیه” پیدا کنید؟ می توانید به یکی از نقاط ضعف و یا قوت خود در بین نظریات آنها پی ببرید؛ اگر قوت بود آنرا افزایش دهید و اگر ضعف بود در پی جبران آن برآیید.۴- ممکن است برداشتی که از نظریات آنها می کنید کاملاً نادرست باشد و آنها واقعاً از گفته های خود قصد و منظوری مداشته باشند. تنها به دلیل اعتقادات و باورهای ذهنی نمی توانید دیگران را متهم کنید.۵- نسبت به پیام های زیرکانه ای که ممکن است نظریات منفی در بر داشته باشند، آگاه باشید (مانند تبلیغاتی که هر روزه به گوشتان می رسد) و به آنها اجازه ندهید تا حس ارزشمندی و اعتبار شخصی شما را زیر سوال ببرند.گاهی اوقات برخی از توهین ها و تحقیرها هستند که برخورد با آنها صورت مناسبی ندارد، اما اگر بتوانید از آنها به نفع خود استفاده کنید، بهترین کار را انجام داده اید.