نوشته های حسین دادخواه

صفر به یک از طلوع کاملِ خورشیدِ AI

حسین دادخواه — Wed, 16 Jul 2025 17:18:28 +0330

دارم در مورد این مینویسم (و همزمان پژوهش میکنم) که کسب و کارهای اینترنتی بعد از طلوع کاملِ خورشیدِ #AI چه بلایی سرشون میاد!مثلا فرض کن فولان سایتی که مدل اصلیِ درآمدش #تولید_محتوا و گرفتن بازدید از گوگل بوده با ظهور PaLM و AI owerview و LLMهایی که قابلیت سرچ دارن و ... چه بلایی سر #بیزینس شون میاد؟به دنیای سرچ های Zero-Click داریم وارد میشیم و الان دم درش ایستادیم!پس خیلی از بیزینس مدل ها تغییر میکنهیا حداقل شاید مدل همون مدل باشه ولی #استراتژی اجرا قطعا تغییر میکنهو کسی که نتونه به موقع تغییر را بپذیره و به خوبی اجرا کنه متاسفانه شکست میخورهتو خواب خرگوشی نریم ۲ سال دیگه موج تعدیل ها رو ببینیم ...به نظرم وقتش شده از صفر به یک حرکت کنیم.بیشتر مینویسم ...و تو این نوشته لیست میشه#تجربه

پول در بیارترین زبان‌های برنامه‌نویسی ۲۰۲۵

حسین دادخواه — Tue, 27 May 2025 15:48:45 +0330

اول هفته رو با یه تحلیل ریز و قوی! از زبان‌های #برنامه_نویسی شروع کنیممنابع این آمار رو به راحتی میتونین با سرچ best-paid programming languages برای سال های ۲۰۲۵ و ۲۰۲۴ پیدا کنین پس منابع رو نمیذارم!خلاصه اش اینه که اگه #تایپ_اسکریپت ، #پایتون یا #جاوا کار میکنین، که خوش به حالتون!اگه #سی_شارپ و #PHP و C++ هستین وضعیت خوبهاگه اون ۶تای بالایی رو نیستین و #گولنگ و #روبی هم نه! که برید یه فکری به حال خودتون بکنیدتصاویر هم گویای همه چیز هست…البته تو این بررسی کاری به انقلاب AI نداشتم که اونم سرجای خودش …در مورد انقلاب AI و اینکه قراره چقدر بیکار بشیم مینویسم به زودی ... :)موفق باشین 😀

ایجاد مدل PIP و افزایش ۴۰٪ بهره‌وری

حسین دادخواه — Mon, 26 May 2025 19:08:40 +0330

این نوشته میتونه کمک کنه عملکرد افراد تیم تا ۴۰٪ بهتر بشه!شما هم احساس می‌کنید که تلاش‌های‌تان در کار به نتیجه نمی‌رسه؟!اون هم‌تیمی پسر/دختر خوبیه و دانش هم داره اما خروجی نداره؟🚀 چرا باید درباره PIP حرف بزنیم؟ برنامه بهبود عملکرد (PIP) به #تیم کمک می‌کنه تا نقاط ضعفشون رو شناسایی کنن و با اهداف مشخص به سمت بهبود حرکت کنن. حالا بیایید نگاهی به استراتژی‌های موثر و جذاب برای طراحی یک PIP بیندازیم! 👀1. SMART Goalsاولین قدم برای بهبود عملکرد، تعیین اهداف #SMART (خاص، قابل اندازه‌گیری، قابل دستیابی، مرتبط و زمان‌بندی شده) هست. طبق آمار Harvard Business Review، استفاده از این اهداف می‌تونه عملکرد رو 20-25 درصد افزایش بده. یعنی با یه #هدف درست، می‌تونی به راحتی عملکرد رو بهتر کنی! 💪پیتر دراکر می‌گه: “آنچه اندازه‌گیری می‌شود، مدیریت می‌شود.” این جمله به خوبی اهمیت تعیین اهداف مشخص و قابل اندازه گیری رو نشون می‌ده.2. Feedback Loopایجاد یه #سیستم بازخورد مستمر خیلی مهمه. بر اساس گزارش Gallup، سازمان‌هایی که به بازخورد اهمیت می‌دن، 14.9% افزایش در عملکرد کارکنانشون دارن. پس حتماً باید به همدیگه بازخورد بدیم و از هم یاد بگیریم! 🔄جک ولش می‌گه: “توانایی یک سازمان در یادگیری و تبدیل سریع آن یادگیری به عمل، بزرگ‌ترین #مزیت_رقابتی است.” و چرخه مستمر بازخورد برای این تبدیل کمک میکنه3. Coaching and Mentoringاستفاده از مربی‌گری و #مشاوره هم می‌تونه به شدت موثر باشه. طبق یه مطالعه، #مربی‌_گری می‌تونه عملکرد رو 20-30 درصد بهبود بده. یعنی یه #مربی خوب می‌تونه بهت کمک کنه تا بهترین نسخه خودت بشی! 🏆 یا شما میتونین مربی نیروتون بشید تا بهترین خودش بشهدر مربی گری این نکته یادتون باشه که مارکوس باکینگهام می‌گه: “بهترین راه برای بهبود عملکرد، تمرکز بر نقاط قوت است.” از نقاط قوت شروع کنین …4. Employee Engagementمشارکت کارکنان در فرآیندهای تصمیم‌گیری هم خیلی مهمه. گزارش Gallup نشون می‌ده که این مشارکت می‌تونه به 21% افزایش در سودآوری منجر بشه. یعنی هرچی بیشتر درگیر بشی، بیشتر سود می‌کنی! 💰برای اینکه افراد تیم بتونن در یه جلسه موثر، در تصمیم‌گیری‌ها مشارکت کنن هم #هوش_هیجانی خودشون اهمیت داره هم شما! پس اگه حس میکنین این موضوع ضعیفه اول اون رو سعی کنین بهبود بدین. دنیل گلمن می‌گه: “هوش هیجانی کلید موفقیت در محیط کار است.”5. Recognition and Rewardsشناسایی و پاداش‌دهی به عملکرد خوب هم تاثیر زیادی داره. طبق گزارش Society for Human Resource #Management، 70% از کارکنان با شناسایی و پاداش‌دهی انگیزه بیشتری پیدا می‌کنن.🎉کتاب “Radical Performance Improvement” نوشته رابرت آستین، که به بررسی استراتژی‌های نوآورانه برای بهبود عملکرد می‌پردازه (من هنوز نخودمش ولی امیدوارم به زودی این اتفاق بیافته)برنامه بهبود عملکرد (PIP) یه فرصت عالی برای رشد و پیشرفت در محیط کاره. با استفاده از استراتژی‌های بالا و با همدلی و همکاری، می‌تونیم به نتایج فوق‌العاده‌ای برسیم. به یاد داشته باشید که هر قدم کوچکی که برمی‌دارید، می‌تونه به موفقیت‌های بزرگ منجر بشه! 🌟#PerformanceImprovement #PIP #Growth #EmployeeEngagement #SMARTGoals #Coaching #Feedback #Training #Recognition #Successامیدوارم این متن براتون جذاب و آموزنده بوده باشه! اگر سوال یا نظری دارید، خوشحال می‌شم بشنوم! 😊

این ۴تا؟!

حسین دادخواه — Mon, 19 May 2025 11:31:17 +0330

این ترکیب قوی و هیجان انگیز از انتشارات خوب انتشارات آریاناقلم | Aryanaghalam Publication امروز به دستم رسیدبسته بندی ساده اما پُر احساسی داشتتمیز و مختصر و مفیدبریم که پُرتوان بخونیم ...شما خوندین؟ اگه خوندین شاخص‌ترین نکته‌ای که ازش گرفتین رو کامنت کنینبرام خیلی ارزشمنده ...

رفیق‌تون چاق باشه، شما هم چاق میشی!

حسین دادخواه — Sat, 10 May 2025 22:20:00 +0330

اگه یکی از دوستای نزدیک‌تون چاق بشه، ۵۷٪ احتمال چاقی شما هم بیشتر میشه.حالا اگه یه دوست نزدیک #موفق داشته باشید، چی میشه؟نیازی به توضیح بیشتر نیست ...منبع: پرفسور کریستاکیس (استاد دانشگاه هاروارد) در #کتاب قدرت شگفت انگیز شبکه‌های اجتماعیِ ما#موفقیت

کد تمیز چه شکلی نوشته میشه؟!

حسین دادخواه — Thu, 08 May 2025 08:22:10 +0330

رابرت سی. مارتین (Robert C. Martin) - تو کتاب “Clean Code” میگه:“Clean code is not written by following a set of rules. Clean code is written by developers who care.”“کد تمیز با دنبال کردن یه سری قوانین نوشته نمی‌شه. کد تمیز رو برنامه‌نویسایی می‌نویسن که براشون اهمیت داره.”شاید این سوال پیش بیاد که "براشون اهمیت داره" یعنی چی؟ به نظر من یعنی عادت کردن به یه سری "روش و منش درست" در کدنویسی. کنت بک (Kent Beck) - در کتاب “Extreme Programming Explained” میگه:“I’m not a great programmer; I’m just a good programmer with great habits.”“من یه برنامه‌نویس فوق‌العاده نیستم؛ من فقط یه برنامه‌نویس خوبم که عادت‌های فوق‌العاده‌ای داره.”این یعنی چی؟ منظورش چه عادتهاییه؟اگه بدونیم کنت بک کیه بهتر میتونیم جواب بدیم!کنت بک (Kent Beck)، یکی از پیشگامان Extreme Programming (XP) و از افراد کلیدی در توسعه روش‌های #چابک (#Agile) ئه.پس این عادت‌ها شامل موارد زیر می‌شن که اغلب در #متدولوژی XP و سایر روش‌های چابک تأکید شده:-- ۱. نوشتن تست‌ها قبل از کد (Test-Driven Development - TDD):کنت بک یکی از مبدعان #TDD هست. این عادت به این معناست که قبل از نوشتن کد اصلی، تست‌هایی برای اون می‌نویسی. این کار باعث می‌شه کدت از همون ابتدا قابل اطمینان باشه و مشکلات کمتری داشته باشه.منبع: کتاب Test-Driven Development: By Example نوشته کنت بک.-- ۲. سادگی در طراحی (#Simplicity):یکی از عادت‌های کلیدی کنت بک اینه که همیشه سعی می‌کنه کدها رو ساده و قابل فهم نگه داره. او معتقده که کد پیچیده باعث مشکلات بیشتر در آینده می‌شه.منبع: کتاب Extreme Programming Explained.۳-- . بازسازی کد (Refactoring):کنت بک تأکید زیادی روی عادت بازسازی کد داره. این یعنی بعد از نوشتن کد، مرتباً اون رو بهبود بدی تا خواناتر و بهتر بشه، بدون اینکه عملکردش تغییر کنه. (ریفکتور کردن اصولی داره که در آینده در موردش می‌نویسم)منبع: کتاب #Refactoring نوشته مارتین فاولر (که کنت بک هم در اون مشارکت داشته).۴-- . همکاری تیمی (Collaboration):او به اهمیت همکاری و ارتباط مؤثر با اعضای تیم تأکید داره. عادت‌هایی مثل برنامه‌نویسی دوتایی (Pair Programming) و بازخورد گرفتن سریع از اعضای تیم، از اصول XP هستن که کنت بک بهشون پایبنده.۵-- . نوشتن کد تمیز و خوانا (#Clean_Code):کنت بک همیشه تأکید داره که کد باید برای انسان‌ها قابل فهم باشه، نه فقط برای ماشین. این عادت باعث می‌شه نگهداری و توسعه کد در آینده راحت‌تر باشه.منبع: کتاب Extreme Programming Explained.-- ۶. بازخورد سریع (Rapid #Feedback):یکی از عادت‌های مهم کنت بک اینه که همیشه به دنبال بازخورد سریع از کد و عملکردش هست. این بازخورد می‌تونه از طریق تست‌ها، ابزارها یا اعضای تیم باشه.من این همه از شلختگی گفتم و نوشتم که بدهی فنی آگاهانه و استراتژیک هست به معنی خوب بودنش نیست! یهو نرید غرق در بدهی فنی بشید! مارتین فاولر (Martin Fowler) - در مقاله “#Technical_Debt Quadrant” مینویسه:“The danger with technical debt, unlike financial debt, is that it doesn’t have an obvious interest rate. It silently grows, slowing down development and making future changes harder.”“خطر بدهی فنی، برعکس #بدهی مالی، اینه که نرخ بهره مشخصی نداره. این بدهی به‌صورت نامحسوس رشد می‌کنه، توسعه رو کند می‌کنه و تغییرات آینده رو سخت‌تر می‌کنه.”#مدیریت #توسعه_نرم_افزار #نرم_افزار

بزرگترین درس کسب و کار: اگه از بدنت مراقبت نکنی، با چی میخوای ادامه بدی؟

حسین دادخواه — Wed, 07 May 2025 15:16:06 +0330

یکی از بزرگ‌ترین درس‌های #موفقیت در #کسب_و_کار اینه:"اگه از بدنت مراقبت نکنی، با چی میخوای زندگی کنی؟! با چی میخوای ادامه بدی؟"امیدوارم این درس رو دیر یاد نگیریم، که خیلی میتونه یادگیری دردناکی بشهسو #مدیریت انرژیِ شخصی، #بهره‌وری رو نابود میکنهکارهای خفن انرژی‌های خفن میخوان! و انرژی خفن وابسته‌اس به #سلامتیضمن اینکه محافظت نکردن از سلامتی، یعنی بدهکار شدن به آیندهو اگه زیادی بدهکار بشیم ممکنه ورشکستگی بیاره! چون بابت هر بدهی‌ایی، یه بهره‌ای باید به بستانکار بدید! نرخ بهره وام سلامتی چنده؟قلب و ریه و گردن و ... شما منتظر نمی‌مونن که یه روزی شما برگردین و از اون #آینده لذتش رو ببرین

من تازه اضافه شدم و کد خیلی شلخته‌ اس

حسین دادخواه — Fri, 02 May 2025 01:07:03 +0330

من تازه به #تیم اضافه شدم و کد خیلی #شلخته‌ است. چطور می‌تونم نظر بقیه رو جلب کنم تا بتونم بهترش کنم؟” #ریفکتوروقتی تازه واردی، تو یه موقعیت سختی هستی:-- باید #اعتبار خودت رو از صفر بسازی-- باید کمی حفاری کنی تا تکنولوژی رو بفهمی-- باید بررسی کنی که چه شرایطی باعث تصمیم‌گیری‌هایی شده که کد رو این شکلی، شکل داده-- باید بیزینس‌ رول‌های اون بخش رو درک کنی (این خیلی مهمه، به قولی ifها الکی به #پروژه -- اضافه نشدن! بفهم چرا اونجان؟! خواهش میکنم اینو جدی بگیرید!!!)-- باید ارزش‌های سازمان رو بشناسی-- باید مطمئن بشی که برای چه کاری #استخدام شدی؟-- و…روابطت خیلی مهم‌تر از وضعیت فعلی کد هست. با احترام، کنجکاوی و ذهن باز برخورد کن. بعضی وقت‌ها چیزهایی که در نگاه اول احمقانه به نظر می‌رسن، دلیل خوبی برای بودن به شکل فعلی‌شون دارن! بعضی وقت‌ها هم راه بهتری وجود داره و تو اینو می‌دونی. احتمالاً به همین خاطر هم تو رو استخدام کردن!بعضی از #بدهی ها قرار نیست، فعلا پرداخت بشن. گاهی یه #نرم_افزار به اندازه کافی خوبه. همه چیز نباید کامل باشه. روی فهمیدن قبل از تغییر تمرکز کن.قبل از اینکه جایی رو شخم بزنی 😀 ببین تست خودکار داره یا نه؟ اگه نداره، ببین بهت فرصت میدن که براش بنویسی؟ اگه نداشت سعی کن سمتش نری!با مدیرهای #محصول و #مدیر_فنی صحبت کن تا بفهمی اونا آینده اون محصول رو کجا و چه شکلی می‌بینن.معیارهای کلیدی که هر سرمایه‌گذاری روی اون محصول رو تعیین می‌کنن شناسایی کن. بعد سعی کن به طور صادقانه ارزیابی کنی که تغییرات پیشنهادی شما، چقدر روی این معیارها تأثیر می‌ذاره؟ حتی می‌تونی یه POC (مدل اولیه) زمان‌بندی کنی تا داده‌ها و بینش‌های بیشتری جمع‌آوری کنی.و در نهایت، اگه شما خفن‌ترین فرد تیم هستی، سعی کن بقیه رو با #pair_programming، #برنامه_نویسی گروهی، #استراتژی فنی و غیره همراه کنی. #هدف اینه که ایده‌هات از دستان دیگران عبور کنه!گاهی هیچ اشکالی نداره که ایده شما، توسط مدیر شما، مطرح بشه! کار کردن در تیم‌ها به خصوص در بدو ورود نیاز به هوش سیاسی داره!سعی کردم از #تجربه بگم … شما هم اگه میتونی به این موارد، تو کامنت‌ها اضافه کن…

وقتی میگن استفاده نمیشه ولی حذفش میکنی و میترکه!

حسین دادخواه — Mon, 28 Apr 2025 17:22:01 +0330

https://www.aparat.com/v/wuo63vr وقتی یه کدی رو که انگار استفاده نشده، حذف میکنی و مثل این بدبخت میترکی😂 علتش شلختگیه که تو پست قبلی👇 یکم در موردش نوشتم ولی این بحث هنوز جای نوشتن و گفتن دارهhttps://lnkd.in/eCX3Kk-aتعریف بدهی فنی هم جالبهبه انتخاب آگاهانه راه حل های سریع و آسان به جای راه حل های بهینه و بلندمدت میگن #بدهی_فنیپس به اون ردپاهای زشتی👷🤪 که تو کد هست و براساس ناآگاهی شکل گرفته بدهی فنی نمیگن، بسته به نوع گندی🤷🏻‍♂️ که زدیم #code_smells یا #code_mess میگن (بد بود یا شلخته)عوامل اصلی ایی که باعث شلختگی میشه اینهاس:-۱- فشار زمانی و عجله در تحویل (Time Pressure) (~25%)---- ددلاین‌های غیرواقعی و فشار مدیریتی برای تحویل سریع و نداشتن برنامه و زمان کافی برای بازنگری کد و …-۱- ضعف در دانش و مهارت #تیم توسعه (Knowledge Gap) (~20%)---- بالاخره بله … 🙂-۲- عدم رعایت استانداردها (Lack of Standards) (~15%)---- میگه قانون بد، بهتر از نداشتن قانونه و مدیر بد بهتر از نداشتنه مدیره------ جمله اول میتونه بدبختتون کنه! چرا؟ چون یه جاهایی که قانون/قرارداد هست و اتفاقا آدم‌های باتجربه‌تری هم اون رو نوشتن، شما میری تو توهم اینکه خودم باید قانون داشته باشم ولو بد!-۳- تغییرات مکرر در نیازمندی‌ها (Requirement Changes) (~15%)---- این همونه که باعث دعوای بین #مدیرمحصول و تیم فنی و … میشه 😀 بعضی‌ها معتقدن تو ایران این دلیل درصدش باید خیلی بیشتر باشه-۴- ضعف در مدیریت پروژه (#Project_Management Issues) (~10%)---- تو خیلی از تیم‌ها چیزی به اسم مدیریت پروژه وجود نداره، من اکثر جاهایی که رفتم تازه شروع کردم به ایجاد فرهنگی که منجر به مدیریت پروژه بشه!-۵- کمبود مستندسازی (Poor Documentation) (~8%)---- اینم که هم تو تیم‌های فنی به عنوان ادا بازی بهش نگاه میکنن هم تو تیم‌های محصول! (البته نه همه)-۶- مشکلات تیمی (Team Issues) (~7%)---- شاید باورتون نشه! اولین تیمی که داشتم به خاطر ایگوی "من میدانم" ۲نفر نابود شد! یه شلختگی هم داشت نفوذ میکرد که جلوی پیشروی رو گرفتم!رابطه #شلختگی با MVPها چیه؟شنیدین که: “کد MVP شما خیلی شلخته‌ است. بندازش دور و از نو شروع کن.”سوال اول اینجاست که آیا واقعا شلخته‌اس یا بدهی داره؟سوال دوم اینه که اصلا مشکل از شلختگی کده یا از دید اشتباه نسبت به #MVP ؟موضوع اینه که اگه یه MVP کار می‌کنه و تونستید بفروشید، یعنی شما به تناسب #محصول و #بازار رسیدید. MVP شما چیزی رو انجام می‌ده که مشتری‌های فعلی و بالقوه‌تون می‌خوان.ما همه از کار کردن روی پروژه‌های جدید خوشمون میاد. اما دور انداختن چیزی که اشتباهه و ساختن دوباره‌اش، #ریسک این رو داره که در این مرحله چیزهای اشتباه بسازیم.پس تا جایی که میشه کد نسخه MVP خودتون رو دور نندازید. به جای اون، روش کار کنید. کم‌کم بهترش کنید.و اگه نمی‌تونید (مثلاً تکنولوژی قدیمی یا منسوخ شده و غیره)، اون وقت وقتشه که درباره دور انداختن و شروع از نو صحبت کنیم. اما این یه مورد خاصه.خیلی از MVPها می‌تونند گسترش پیدا کنند. احتمالاً MVP شما هم خوبه.من یکبار تجربه بازنویسی و ۲بار تجربه اصلاح تدریجی رو (هر ۳ در شرایط واقعا بد!) داشتم و خداراشکر هر دو #تجربه هم موفق بود.قطعا شما هم تجربیاتی دارین، تا حالا با این معضل روبرو شدید؟ دور انداختن یا دور ننداختن؟ چطور حلش کردید؟

این کد به درد نمیخوره باید از اول بنویسیم!، بنویسیم؟

حسین دادخواه — Sun, 27 Apr 2025 22:04:59 +0330

این کد به درد نمیخوره باید از اول بنویسیم!بدهی فنی داره نمیذارم مرج بشه!این نسخه MVP هست و بعدا از اول مینویسیم!و … هزاران جمله دردناک آشنای دیگه که گاهی شک میکنیم واقعا درستن یا نه؟ و اکثرا هم عامل دعوای #بیزینس و #فنی میشه!در کتاب “The Pragmatic Programmer” نوشته آندرو هانت و دیوید توماس نوشته شده:“#Technical_debt is not inherently bad. It’s a conscious choice that we make to achieve a goal. The #mess, on the other hand, is often the result of neglect and poor practices.”یعنی بدهی فنی الزاما هم بد نیست، #بدهی_فنی میتونه یک انتخاب آگاهانه باشه که به شما اجازه میده تا سریع‌تر وارد #بازار بشید ولی کاملا اسمش روشه! بدهی! شما باید یه روز پرداختش کنی و گاهی چِک میدی و گاهی قسطی پرداختش میکنی.من با پرداخت قسطیِ بدهی‌ها، بیشتر موافقم.اما تو همین متن میخونیم که واااااااااای از #mess ! به نظرم بهترین ترجمه براش شلختگی کده.بدهی فنی یه سری ویژگی داره که شلختگی نداره:-- آگاهانه و استراتژیکه-- قابل اندازه گیری و در نتیجه قابل مدیریته-- هدف و تاریخ سر رسید داره! (هر بدهی ایی یه تاریخ سر رسید داره! چیزی که بهش در دنیای #نرم_افزار دقت نمیشه)ولی شلختگی این ویژگی‌ها رو ندارهاحتمالا زیاد این غُر غُر رو از همکارهای من شنیدین که "این کد باید #ریفکتور بشه!" و به عنوان یه #مدیر بعضی وقت‌ها پیش خودتون میگین: این ریفکتورها کی تموم میشه؟ مگه همین چند وقت پیش ریفکتور نکرده بود؟ آقا اصلا کسی اسم ریفکتور رو آورد آویزون میشه و …. 🙂علتش میدونین چیه؟اول اینکه hashtag#برنامه_نویس ها بیشتر از اینکه کد بنویسن مجبورن کد بخونن (کد خودشون یا همکارشون)و دوم۲ یه قانون اساسی و بنیادی توی برنامه‌نویسیه: خوندن کد از نوشتن کد سخت‌تره.” - جوئل اسپولسکینتیجه اش چی میشه؟ -> انجام بیشترِ کارِ سخت تر!و اگه حواسمون نباشه به تفاوت بدهی آگاهانه و شلختگی ناآگاهانه میافتیم تو لوپ ریفکتور و باگدر مورد تفاوت این ۲تا و بحث بازپرداخت قسطی بدهی‌ها خیلی حرف‌ها دارم که کم کم مینویسماین شروع این داستان بود ....نظر شما چیه؟

ساده ترین راهِ امن کردن عکس‌های کوچیک

حسین دادخواه — Sat, 26 Apr 2025 12:42:36 +0330

فکر کن داریم با یه سری عکس حساس کار می‌کنیم مثل عکس‌های هویتی که حجم بالایی ندارن ولی مهمه که امنیت‌شون حفظ بشه. 😬 حالا، اگر کسی به این #اطلاعات دسترسی پیدا کنه، همه چیز به هم می‌ریزه! 🔥 (تو ایران زیاد بهم ریخته!)اینجا باید یه شکل دیگه عکس‌ها رو ذخیره کنی که یه حداقل‌هایی رو رعایت کرده باشی! من سعی کردم تو یه کد ساده که تو gist هم گذاشتم این نیاز رو رفع کنم (قطعا میشه بهترش کرد)https://lnkd.in/e4vAPF4Wکلاس SecureImageEncryption با استفاده از الگوریتم AES-256-CBC، تصاویر رو رمزنگاری می‌کنه تا فقط افرادی که مجاز هستن بتونن بهشون دسترسی داشته باشن. 🔑 به این ترتیب، #امنیت اطلاعاتت حفظ میشه و خیالت راحت میشه! 😊کلاس SecureImageEncryption برای #رمزنگاری تصاویر با استفاده از #الگوریتم AES-256-CBC طراحی شده. این کلاس تصاویر رو به صورت رمزنگاری شده ذخیره می‌کنه و امکان رمزگشایی اون‌ها رو هم فراهم می‌کنه.چرا این کار انجام میشه؟ 🤔-- حفاظت از داده‌ها: تصاویر ممکنه حاوی اطلاعات حساس باشن. رمزنگاری از دسترسی غیرمجاز به این اطلاعات جلوگیری می‌کنه. -- امنیت در ذخیره‌سازی: با رمزنگاری تصاویر قبل از ذخیره‌سازی توی #پایگاه_داده یا سیستم فایل، حتی اگه کسی به داده‌ها دسترسی پیدا کنه، محتوای اصلی تصاویر قابل فهم نخواهد بود. -- کنترل دسترسی: با استفاده از کلیدهای رمزنگاری، می‌تونی دسترسی به تصاویر رو کنترل کنی و مطمئن بشی که فقط افراد مجاز می‌تونن بهشون دسترسی داشته باشن. چطور کد کار می‌کنه؟ این کد به سادگی تصاویر رو با استفاده از یک کلید رمزنگاری و یک نماد تصادفی رمزنگاری می‌کنه. 🔒 اول، یک مقدار پایه به نام baseSalt تعریف میشه که برای ساخت کلید رمزنگاری استفاده میشه. بعد، با ترکیب این مقدار با زمان فعلی، یک کلید قوی تولید میشه که به کمک اون، تصاویر رمزنگاری و ذخیره می‌شن تا فقط افراد مجاز بتونن بهشون دسترسی داشته باشن. نکات امنیتی مهم: 🔐-- baseSalt قوی: baseSalt باید خیلی پیچیده و منحصر به فرد باشه. از salt های ساده و قابل حدس زدن خودداری کن! ❌-- ذخیره‌سازی امن baseSalt: baseSalt نباید در کد یا فایل‌های قابل دسترس عموم ذخیره بشه. بهتره اون رو در یک محیط امن مثل متغیرهای محیطی یا یک فایل پیکربندی امن ذخیره کنی. 🗝️امیدوارم این نسخه با نیازهای شما مطابقت داشته باشد!البته این امکان هم وجود داره تا از آبجکت استوریج ها با قابلیت انکریپشن و پالیسی های دقیق در پروژه استفاده کنیم:MINIOCEPH...به چند دلیل:امکان ثبت پالیسیامکان جداسازی سرور فایل از سرور اپلیکیشنامکان ایجاد صندوق های فایل مجزاامکان ریپلیکیت کردن فایل هاامکان تریگر کردن هر رویداد روی فایل های مشخص برای اجرا شدن میکروسرویس، برای مثال، در MINIO این امکان وجود داره تا برای فایل هایی که آپلود میشن یک Trigger بنویسید تا یک میکروسرویس برای ویروس یابی رو فعال کنه و ...ولی گاهی میخوای ساده و سریع و مطمئن کار کنی و راه حلی که پیشنهاد دادم جواب میده

۲۱ قانون طلایی برای تست‌نویسی بهتر

حسین دادخواه — Fri, 25 Apr 2025 15:36:47 +0330

اگه می‌خوای تست‌نویسی‌هات رو حرفه‌ای‌تر کنی و رازهای تست‌های موفق رو بدونی، این پست پر از نکات کاربردیه که نباید از دست بدی! 🔥واقع‌بین باشیم باید اول این پست رو save کنیم که بعدا بهش رجوع کنیم... 😉– 1 - قانون AAA (Arrange, Act, Assert): 🛠️➡️⚡➡️✔️ یکی از معروف‌ترین و پایه‌ای‌ترین قوانینه که میگه تست باید تو سه مرحله انجام بشه: آماده‌سازی شرایط (Arrange)، اجرای عمل (Act)، و بررسی نتیجه (Assert).– 2 - قانون F.I.R.S.T: 🚀🔗🔁✅⏰میگه #unit_testها باید:سریع (Fast)مستقل (Independent)قابل تکرار (Repeatable)خودکار (Self-validating) وبه موقع (Timely) باشن.این قانون خودش یه دنیا حرف داره! مثلاً قانونی که به عنوان #Reliability یا #Trustworthiness شناخته میشه، بخشی از اصول F.I.R.S.Tه. به‌ویژه اصول Self-validating (خودکار و قابل اعتماد بودن تست) و Timely (نوشتن تست به موقع) به این مفهوم اشاره دارن که تست‌ها باید قابل اعتماد باشن و رفتارهای مهم و بحرانی سیستم رو پوشش بدن.اما اگه دقیق‌تر بگیم، این مفهوم ممکنه به قانون Test Critical Paths هم مرتبط باشه که بر پوشش مسیرها و عملکردهای مهم سیستم تأکید داره.– 3 - مجموع قوانین #Test_Critical_Paths 🧭مسیرهای بحرانی (Critical Business Paths): فرآیندهایی که برای عملکرد اصلی سیستم ضروری‌ان، مثل فرآیند خرید تو یه فروشگاه آنلاین 🛒 یا ورود به سیستم تو یه وب‌اپلیکیشن 🔑.مسیرهای پرخطر (High-Risk Paths): بخش‌هایی از کد که احتمال بروز خطا یا شکست توشون بیشتره، مثل عملیات پیچیده، کدهای مرتبط با محاسبات مالی 💰 یا منطق پیچیده.مسیرهای پرتکرار (High-Frequency Paths): ویژگی‌ها یا مسیرهایی که بیشتر توسط کاربران استفاده میشن، مثل دکمه جستجو 🔍 یا فرم ثبت‌نام 📝.مسیرهای وابسته به منابع خارجی (External Dependency Paths): بخش‌هایی که به سیستم‌های خارجی مثل دیتابیس 🗄️، API یا سرویس‌های شخص ثالث وابسته‌ان.شرایط لبه (Edge Cases): ورودی‌ها و سناریوهایی که شاید به ندرت رخ بدن ولی می‌تونن سیستم رو دچار مشکل کنن، مثل ورودی‌های صفر، مقادیر خیلی بزرگ یا کوچک و داده‌های نامعتبر.عملکرد و زمان پاسخ (Performance and Response Time): اطمینان از اینکه مسیرهای مهم تحت بار زیاد یا تو شرایط خاص همچنان درست و با سرعت مناسب کار می‌کنن ⏳.امنیت و اعتبارسنجی (Security and Validation): بخش‌هایی که به تأمین امنیت سیستم مرتبط‌ان، مثل احراز هویت کاربران 🔒 یا محافظت در برابر ورودی‌های مخرب 🛡️.– 4 - قانون Isolation (ایزوله بودن): 🚧 هر تست واحد باید به صورت مستقل اجرا بشه و به تست‌های دیگه یا محیط خارجی وابسته نباشه.– 5 - قانون One Assertion Per Test: ☝️ هر تست باید فقط یک شرط (assertion) رو بررسی کنه تا تست‌ها ساده و قابل فهم باشن.– 6 - قانون Test Behavior, Not Implementation: 🔍 تست‌ها باید رفتار کد رو بررسی کنن، نه جزئیات پیاده‌سازی اون. یه مثال بزنم تا شفاف شه 🌟:فرض کن یه تابع داریم که عددی رو دو برابر می‌کنه:public function double(int $number): int { return $number * 2; // پیاده‌سازی}تست درست (بررسی رفتار):$this->assertEquals(10, $this->double(5)); // آیا نتیجه صحیحه؟تست اشتباه (بررسی پیاده‌سازی):$this->assertStringContainsString('* 2', $this->getMethodBody('double')); // آیا تابع حتماً از ضرب در 2 استفاده کرده؟– 7 - قانون Mock External Dependencies: 🧪 وابستگی‌های خارجی مثل دیتابیس یا API باید تو تست‌های واحد با mock جایگزین بشن تا تست‌ها سریع و مستقل باشن. البته این قانون تو unit testها بیشتر مطرحه و تو بعضی از مدل‌های تست منطقیه که نقض بشه!– 8 - قانون Keep Tests Small and Focused: 🎯 تست‌های واحد باید کوچک و متمرکز بر یک وظیفه خاص باشن تا به راحتی قابل فهم و نگهداری باشن. شاید بگی: “آیا این همون قانون ایزوله بودنه؟” 🤔 نه دقیقاً!#Isolation: بر استقلال تست‌ها و قطع وابستگی به عوامل خارجی تأکید داره.Small and Focused: بر کوچک و متمرکز بودن هر تست بر یک وظیفه خاص تأکید می‌کنه. این دو قانون مکمل هم‌ان؛ تست‌های کوچک و متمرکز معمولاً راحت‌تر مستقل و ایزوله نگه داشته میشن– 9 - قانون Avoid Side Effects: 🚫💥 تست‌های واحد نباید هیچ‌گونه اثر جانبی ایجاد کنن؛ تغییرات باید محدود به محدوده تست باشن. یعنی تست‌ها نباید وضعیت سیستم یا داده‌های مشترک رو تغییر بدن که روی اجرای سایر تست‌ها یا عملکرد کلی سیستم تأثیر بذاره.– 10 - قانون Test Edge Cases: 🧐 تست‌های واحد باید شرایط لبه (edge cases) و سناریوهای غیرعادی رو هم پوشش بدن. یعنی اون سناریوهایی که احتمال میدیم می‌ترکه! 💣– 11 - قانون Keep Tests Deterministic: 🔄 تست‌های واحد باید همیشه نتایج یکسانی تولید کنن و نباید به شرایط تصادفی یا متغیرهای خارجی وابسته باشن. فرض کن یه تست داریم که بررسی می‌کنه آیا برنامه همیشه عددی تصادفی بین 1 تا 10 تولید می‌کنه.غیردترمینیستیک (اشتباه): هر بار که تست اجرا بشه، خروجی ممکنه متفاوت باشه و باعث شکست تصادفی تست بشه.دترمینیستیک (درست): تو تست، عدد تصادفی رو شبیه‌سازی (mock) می‌کنیم تا همیشه مقدار مشخصی برگردونه و نتیجه تست ثابت باشه. تست همیشه باید نتیجه یکسانی بده، صرف‌نظر از زمان یا شرایط اجرای اون.– 12 - قانون Fail Fast: ⚠️ تست‌ها باید در صورت بروز خطا به سرعت شکست بخورن و اطلاعات کافی برای شناسایی مشکل ارائه بدن. و از همه مهم‌تر باید تو اولین نقطه‌ای که خطا رخ داده بترکه! 💥 یعنی چی؟ یعنی فرض کن تابع شماره ۱ باید یه ورودی از یه نوع خاصی بگیره و نگرفته، ولی اونجایی که خطا داده ۲ خط جلوتر یا ۲ تا لایه جلوتره و این یعنی سریع fail نشده.– 13 - قانون No Silent Failures: 🔊 هیچ تستی نباید بدون ارائه اطلاعات در مورد دلیل شکست، به پایان برسه. لطفاً یه چیزی بگو! 😅– 14 - قانون Setup Once, Reuse Often: ♻️ برای تست‌های مشابه، از setupهای مشترک استفاده کنین تا از تکرار کد جلوگیری بشه.– 15 - قانون DRY (Don’t Repeat Yourself): 🛑 کدهای تکراری تو تست‌ها باید به توابع کمکی یا داده‌های مشترک منتقل بشن، ولی این قانون رو با دقت خیلی زیاد استفاده کنین چون می‌تونه اصول استقلال، صراحت و شفافیت رو تو تست‌ها نقض کنه.– 16 - قانون Context Matters: 🌐 تست‌ها باید مشخص کنن که تو چه شرایطی و با چه ورودی‌هایی اجرا شدن. این قانون میگه زمینه و متغیرهای اجرای تست مهمه و یکی از ابزارهای دستیابی به Trustworthiness هست که با درک دقیق محیط، اعتمادپذیری سیستم افزایش پیدا می‌کنه.– 17 - قانون Refactor with Confidence: 💪 تست‌ها باید جوری باشن که بتونیم با اطمینان کد رو بازسازی یا بهینه‌سازی کنیم، بدون نگرانی از تغییر رفتار کد. برای سنجش اینکه به این هدف رسیدیم یا نه، یه سری شاخص معروف شده مثل اینکه کاوریج تست بالای ۸۰٪ باشه.– 18 - قانون Avoid Over-Mocking: 🙅‍♂️ از mock بیش از حد استفاده نکنین، چون ممکنه تست‌ها رو از واقعیت دور کنه.– 19 - قانون Test Naming Convention: 📝 برای نام‌گذاری تست‌ها یه الگوی ثابت و استاندارد داشته باشین، مثل: Should__When_. در این مورد مفصل در یک متن دیگه، خواهم نوشت! ✍️– 20 - قانون Test What You Own: 🏠 فقط بخش‌هایی از کد که مسئولیتشون با شماست رو تست کنین و به وابستگی‌های خارجی اتکا نکنین.– 21 - قانون Readable Assertions: 👓 عبارات assertion باید جوری نوشته بشن که به تنهایی منظور و هدف تست رو بیان کنن.

برای موفقیت باید به چیزهای خیلی خوب نه بگی!

حسین دادخواه — Sun, 20 Apr 2025 17:34:13 +0330

برای موفقیت باید به چیزهای خیلی خوب نه بگی! سخته یه چیزی رو دوست داشتی باشی ولی ذهنت رو آروم کنی و بگی نه! علی ali khosravi داشت میگفت برنامه ریزی کرده، عید رو روی هوش مصنوعی مطالعه عمیقی داشته باشهبا شناختی که ازش دارم میدونم موفق میشهخیلی دلم میخواست بگم منم هستم، با هم بریم جلوولی به خاطر هدف دیگه‌ای که دارم سکوت کردمبرای موفقیت باید به چیزهای خیلی خوب نه بگی! هرچی بیشتر نه بگی اون آره ایی که به هدف الی گفتی قوی تر میشهشاه کلید اصل گرایی همین نه گفتنه#تجربه #شب_نشین

آمریکا، عشق و مذاکره

حسین دادخواه — Sun, 20 Apr 2025 16:08:50 +0330

https://www.aparat.com/v/rcp986x یکی زیر همین ویدئو نوشته: درسته که آمریکا رو به زور از سرخپوست‌ها گرفتنولی الان ابرقدرت جهان شده!!سرخپوستی که نسل کشی شد و الان دیگه زیر خاکه، ابرقدرت شدن به چه دردش میخوره؟!خبر دارید چند میلیون انسان قتل عام شد؟!خیلی این عشق و علاقه به آمریکا عجیبه در بعضی ...*مذاكرات اجداد ترامپ …*پيشنهادها و درخواست ها !*چقدر همه چيز آشنا و تكراريست …*پ.ن: مخالف مذاکره نیستم ولی مذاکره ی احمقانه چیز بدیه!

دردسرهای بیزینس با فنی‌! به روایت آمار

حسین دادخواه — Fri, 18 Apr 2025 13:43:26 +0330

دعوای بیزینس و فنیاگه مدیرعامل یه شرکت‌ #نرم‌_افزاری یا #مدیر_فنی هستین این نوشته رو حتما بخونید:اول یه سوزن به خودمون میزنم بعد باید پرتقال فروش رو پیدا کنیم 😀طبق آمار رسمی نصر، سال ۱۴۰۱ حدود ۲۵۰۰ تا شرکت نرم‌افزاری فعال داشتیم. حالا جالب‌تر اینه که تو سال ۱۴۰۲ این عدد رسید به ۷۵۰۰ تا! و نکته مهم اینه که حدود ۴هزار تاشون یه #درد مشترک دارن📊 طبق گزارش McKinsey در سال 2023، در کشورهای #در_حال_توسعه حدود 47% از مدیران عامل و در کشورهای توسعه یافته حدود 78% شون از #مشاوره فنی استفاده میکنن.اینجا مهم میشه و مشخص میشه که چرا آمار بالا رو دادمتو گزارش Deloitte Digital Transformation Survey 2023 برای کشورهای درحال توسعه اومده که ۶۳٪ از شرکت‌های نرم‌افزار حدود ۸۰٪ از مشکلات‌شون به مدیرهای فنی شون ربط داره!و این بده!این آمار رو از ۱۲۰۰ شرکت نرم افزاری تو ۱۵تا کشور درحال توسعه گرفتناینو باید بگم که خیلی جالبه که آمار ۴۷٪ ایی McKinsey با آمار ۶۳٪ Deloitte Digital تقریبا همدیگه رو دارن تایید میکنن! ولی ۲تا گزارش دیگه هم هست که وقتی ترکیب‌شون کنی به آمارها و اطلاعات جالبی میرسییه سری شرکت هستن که مشکل اصلی‌شون فنی یا مدیرفنیه! و علتش این موارده:براساس گزارش ترکیبی McKinsey Digital و Stack Overflow Developer Survey 2023:کشورهای در حال توسعه:--- ضعف در درک نیازهای کسب‌وکار توسط #تیم فنی (35%)--- ضعف در #تفکر_سیستمی و #معماری نرم‌افزار (25%)--- مشکلات #مدیریت تیم و ارتباطات درون‌تیمی (20%)--- ضعف در حل مسئله و تصمیم‌گیری فنی (15%)--- عدم همسویی #استراتژی فنی با نیازهای بیزینس (30%)--- چالش‌های مقیاس‌پذیری و بدهی فنی (25%)--- ضعف در مدیریت تغییرات و چابکی سازمانی (20%)--- مشکلات در نوآوری و پیاده‌سازی تکنولوژی‌های جدید (15%)(بررسی روی 3000+ شرکت نرم‌افزاری در 40 کشور)۲تا گزارش مهم مرتبط دیگه هم داریم یکی از McKinsey Digital تو سال ۲۰۲۳ و اون یکی هم از Gartner IT Industry Report تو همون سالمیگه ۸۰٪ علت شکست شرکت‌ها و #استارتاپ های نرم افزاری در کشورهای درحال توسعه و توسعه یافته این موارده:--- ضعف در مدیریت پروژه (35%)--- کمبود نیروی متخصص (25%)--- مشکلات مالی و #نقدینگی (20%)--- عدم تطابق #محصول با نیاز #بازار (40%)--- مشکلات مقیاس‌پذیری (25%)--- رقابت شدید بازار (15%)تو این گزارش McKinsey از ۲۵۰۰ در ۳۰ کشور و Gartner IT از ۱۸۰۰ تا شرکت در ۲۵ کشور آمار رو گرفتن و تحلیل کردندر کنار این آمارها من دوست داشتم بدونم مشکلات رایجی که معمولا اطراف‌مون میبینیم چقدر در شکست بیزینس های نرم افزاری اثر داشته 🙂این موارد، اینقدر! در شکست این کسب و کارها اثر داشته! (بدون شرح):بر اساس Stack Overflow Developer Survey 2023 و State of DevOps Report 2023:--- مشکلات مدیریتی و رهبری تیم‌های فنی (شامل دخالت‌های نامناسب مدیریتی): 32%--- بدهی فنی و مشکلات زیرساختی: 29%--- کمبود مهارت و تجربه در تیم‌های فنی: 24%حالا سوال اینجاست که چرا وقتی همچین دغدغه مهمی وجود دارد مدیرهای عامل در مرحله اول به عنوان حافظان کسب و کار و بعد خود همکارهای محترم من، از مشاوره استفاده نمیکنن؟اینطور که آمارهای مختلف داره نشون میده ۴۳٪ از CEO ها درک درستی از ارزش این سرمایه گذاری ندارن مثلا نمیتونن لمس کنن که ROI این هزینه‌ای که برای گرفتن مشاوره میدن (که کم هم نیست) چقدر براشون آورده داره در نتیجه ترجیح میدن که به صورت داخلی مشکل‌شون حل بشه (بالاخره یه CTO استخدام کردن برای همین دیگه!)و علت بعدی هم که خیلی نرخش بالاست مقاومت های فرهنگیه که ۳۸٪ اثر گذاره! مثلا مدیرعامل یا مدیرفنی پذیرش مشاوران خارج از تیم رو ندارن و مورد بعدی ترس از افشای اطلاعات سازمانیه ولی یه سندروم جالب هم اینجا اذیت میکنه که بهش میگن سندروم “اینجا اختراع نشده”! NIH (Not Invented Here)این سندروم چی میگه؟افراد یا سازمان‌ها از پذیرش یا استفاده از ایده‌ها، محصولات، فناوری‌ها یا راه‌حل‌هایی که در خارج از سازمان، تیم یا محیط خودشان توسعه یافته‌اند، خودداری می‌کنند یا به آن‌ها با شک و تردید نگاه می‌کنند. ایده‌ها، محصولات یا راه‌حل‌هایی که خارج از سازمان یا توسط دیگران ایجاد شده‌اند، با مقاومت یا بی‌تفاوتی مواجه می‌شوند. این نگرش می‌تواند ناشی از احساس غرور سازمانی، تمایل به اختراع مجدد چرخ به جای استفاده از راه‌حل‌های موجود، یا ترس از ناشناخته‌ها باشد.یه مشکل دیگه هم اینه که پیدا کردن یه مشاور فنی که هم تخصص داشته باشه، هم تعهد، سخته!اینجاست که اگه نیاز به کمک داشتی، من هستم! پیام بده، شاید بتونم کمکت کنم. 😉

نردبان شغلی گوگل: از تازه‌کار تا رهبر جهانی!

حسین دادخواه — Mon, 03 Mar 2025 13:22:09 +0330

نردبان شغلی گوگل: از تازه‌کار تا #رهبر جهانی!مهندسای #گوگل چطور مسیر شغلی‌شون رو طی می‌کنن و به کجا می‌رسن؟خب، گوگل یه چارچوب خیلی دقیق و جذاب داره به اسم “نردبان شغلی” (که جدیداً به “پروفایل شغلی” تغییر اسم داده). این #سیستم به مهندسا کمک می‌کنه تا بدونن کجا هستن، به کجا می‌تونن برسن و چطور می‌تونن مسیر پیشرفت‌شون رو مدیریت کنن؟#نردبان_شغلی گوگل میتونه الگوی خوبی برای برنامه‌های آینده شغلی و توسعه و سنجش عملکرد و ... در شرکت‌های مختلف باشهچون در #گوگل تنوع خیلی زیاده این نردبان هم به شکلی طراحی شده که با همه نیازهاشون منطبق باشهبرای همین میتونه با نیازهای شرکت‌ها #تیم های ما هم منطبق باشه یا با یه تغییر کوچک منطبق بشهدر #نردبان_شغلی هر سطح بر اساس چهار تا بُعد اصلی تعریف شده: مشارکت (#Collaboration)، چالش (#Complexity)، #قدرت_نفوذ (#Influence) و تخصص (#Expertise).📌 مشارکت (Collaboration) سطح ۳: تازه‌کاری و وظایف ساده رو با دقت انجام می‌دی و گاهی نیاز به کمک داری. سطوح بالاتر: پروژه‌های پیچیده‌تر رو #مدیریت می‌کنی، #تیم رو هدایت می‌کنی و مسئولیت کل پروژه‌ها رو می‌گیری. سطوح استراتژیک: #استراتژی تیم و سازمان رو تعیین می‌کنی.📌 چالش (Complexity) سطح ۳: یاد می‌گیری ابزارها رو استفاده کنی و بدونی کی کمک بخوای. سطوح بالاتر: مسائل پیچیده‌تر رو حل می‌کنی و راه‌حل‌های خلاقانه ارائه می‌دی. سطوح استراتژیک: مسائل کلان رو حل می‌کنی و روی سرمایه‌گذاری‌های شرکت تأثیر می‌ذاری.📌 قدرت نفوذ (Influence) سطح ۳: توی تیم خوب کار می‌کنی و تأثیر مثبت داری. سطوح بالاتر: با تیم‌ها و ذی‌نفع‌ها #ارتباط قوی‌تری برقرار می‌کنی و تیم‌ها رو #هماهنگ می‌کنی. سطوح استراتژیک: تأثیرت به کل سازمان و صنعت می‌رسه.📌 تخصص (Expertise) سطح ۳: با تکنولوژی‌ها و #معماری‌ ها آشنا می‌شی. سطوح بالاتر: در چند حوزه متخصص می‌شی و مرجع می‌شی. سطوح استراتژیک: #متخصص تمام‌عیار می‌شی که توی کل #صنعت بهت رجوع می‌کنن.📊 سطوح شغلی مهندسان گوگل- سطح ۱: #کارآموز (Intern)دانشجوهایی که تازه وارد گوگل شدن.وظیفه‌شون یادگیری ابزارها و کار روی پروژه‌های کوچیکه.نیاز به راهنمایی: خیلی زیاد.- سطح ۲: #مهندس مبتدی (#Junior #Software #Engineer)تازه‌کارهایی که تجربه کمی دارن.وظیفه‌شون انجام کارهای ساده تحت نظارت و یادگیری اصول پایه‌ایه.نیاز به راهنمایی: زیاد.- سطح ۳: مهندس نرم‌افزار (Software Engineer I)شروع واقعی مسیر #مهندسی در گوگل.کار روی وظایف مستقل ولی با نظارت.نیاز به راهنمایی: متوسط.- سطح ۴: مهندس نرم‌افزار متوسط (Software Engineer II)مستقل‌تر می‌شی و می‌تونی پروژه‌های پیچیده‌تر رو مدیریت کنی.نیاز به راهنمایی: کم.- سطح ۵: مهندس ارشد (Senior Software Engineer)پروژه‌های بزرگ‌تر رو مدیریت می‌کنی و راهنمایی مهندسای تازه‌کار رو به عهده داری.نیاز به راهنمایی: حداقل.- سطح ۶: مهندس استاف (Staff Software Engineer)تیم‌های بزرگ‌تر رو هدایت می‌کنی و توی تصمیم‌گیری‌های استراتژیک شرکت می‌کنی.نیاز به راهنمایی: هیچ، از اینجا به بعد خودت #راهنما هستی.- سطح ۷: مهندس ارشد استاف (Senior Staff Software Engineer)پروژه‌های چند تیمی رو هدایت می‌کنی و راه‌حل‌های استراتژیک ارائه می‌دی.- سطح ۸: مهندس اصلی (Principal Software Engineer)به یه متخصص برجسته تبدیل می‌شی که استراتژی‌های فنی سازمان رو تعیین می‌کنه.- سطح ۹: مهندس ممتاز (#Distinguished_Engineer)#رهبر فنی کلیدی در سطح سازمان و صنعت.- سطح ۱۰: گوگل فلو (Google Fellow)بالاترین سطح مهندسی در گوگل.رهبر فنی جهانی که تأثیرش فراتر از گوگل و روی کل صنعت فناوریه.نیاز به راهنمایی: هیچ، خودت #الهام‌_بخش دیگرانی.

میکرو پست: حرف زدن بسه! کدتو نشون بده

حسین دادخواه — Mon, 24 Feb 2025 09:54:47 +0330

من اینقدر از این تجربه ها داشتم هرچی بگم احتمالا به یک یا چند نفر برمیخورهدر نتیجه، هیچی... 😅 امید عزیز این رو نوشته بود و به نظر ارزشش رو داشت باهاتون به اشتراک بذارمنمیدونم امید تو ویرگول هم هست یا نه؟

دانش‌بنیان‌های عزیز دست به جیب شدن! ولی نه برای نیروهاشون

حسین دادخواه — Sat, 22 Feb 2025 14:37:41 +0330

این خبر جدید نیست ولی به اندازه کافی عجیب و بد هستدانش‌بنیان‌های عزیز دست به جیب شدن!البته نه برای کارمندهاشون!یه خبر باحال! 😅 انگار ۵۰ تا از این شرکت‌های دانش‌بنیانمون (که مثلاً قرار بود آینده مملکت رو بسازن 🏗️) یه ماه تموم داشتن روزی ۵۰ میلیون #دلار #تتر می‌خریدن!حالا بذارید یه جور دیگه بگم که بهتر متوجه بشید: 🤔 روزی ۴ هزار میلیارد تومن پول رو هوا می‌کردن واسه خرید تتر! یعنی قشنگ معلومه که این وسط یه خبراییه! 💸💸عضو اتاق بازرگانی هم که انگار تازه از خواب بیدار شده 😴، اومده تو توییتر این خبر رو داده. حالا خوبه بانک مرکزی یهو دید اوضاع داره شیر تو شیر میشه و گفت “نچ نچ، دیگه از این خبرا نیست!” 🚫دلار و تتر هم که، هی میرن بالاتر و بالاتر… رسیدن به ۸۱ هزار تومن! 📈حالا یکی نیست بپرسه این شرکت‌های #دانش_بنیان که قرار بود با علم و دانش و نوآوری حال مملکت رو خوب کنن، چرا یهو تبدیل شدن به صرافی‌های سیار؟!خلاصه که بانک مرکزی هم گفته “فعلاً دست نگه دارید” 🛑 ولی این “فعلاً” رو خوب اومد… انگار قراره بعداً دوباره بریم تو کار خرید و فروش! 😉پ.ن: به قول قدیمیا، این وسط یه کاسه‌ای زیر نیم کاسه هست که ما خبر نداریم! 🤫#دانش_بنیان_یا_دلار_بنیان #تتر_به_از_دانش 🎪🎭🎪

ارتباطات خوب در تیم‌های ریموت

حسین دادخواه — Wed, 19 Feb 2025 10:57:09 +0330

داری با توسعه‌دهنده‌های وب از راه دور کار می‌کنی؟ 🤔 ارتباط خوب کلید موفقیته! اینجا چند تا نکته هست که بهت کمک می‌کنه کارها رو روان و پربازده نگه‌داری:تصور کن داری یه خونه می‌سازی، ولی چشمت بسته‌س! 🏠 بدون دستورالعمل‌های واضح، ابزار و همکاری، همه‌چیز به هم می‌ریزه. #مدیریت توسعه‌دهنده‌های وب از راه دور هم هیچ فرقی نداره؛ شکاف‌های ارتباطی می‌تونه حتی بهترین پروژه‌ها رو به هم بریزه.اول از همه، باید انتظارات رو خیلی واضح مشخص کنی. 📋 کارها، مهلت‌ها و تحویل‌ها رو دقیق بگو تا هیچ‌کس سردرگم نشه. از ابزارهای همکاری مثل #Slack یا موارد مشابه برای بروزرسانی‌های سریع، #Trello یا #Jira برای مدیریت وظایف و #Loom برای توضیحات غیرهمزمان استفاده کن. هر از چندگاهی ویدیو چک‌این‌های منظم بذار تا پیشرفت‌ها رو هماهنگ کنی، مشکلات رو حل کنی و ارتباط #تیم رو تقویت کنی. 💪در نهایت، یه فرهنگ «زیاد ارتباط برقرار کردن» رو تشویق کن که توش سوال‌ها و بروزرسانی‌ها به راحتی رد و بدل بشه و مطمئن بشی که همه متصل، متمرکز و تولیدکننده‌ن. 🌟برای پر کردن گپ‌های ارتباطی در تیم‌های #ریموت، استفاده از روش‌های مؤثری مثل #برنامه‌نویسی_جفتی (pair programming)، جلسات #گرومینگ (grooming) و جلسات #رترو (retro) می‌تونه به شدت مؤثر باشه. به قول کاتلر در کتاب “Marketing 4.0”: “در دنیای دیجیتال، ارتباطات مؤثر و همکاری در تیم‌های مجازی ضروری است.”آموزش خلاهای ارتباطی در ارتباط‌های غیرمستقیم هم خیلی مهمه. 📚 به عنوان مثال، در کتاب “Crucial Conversations” نوشته پاتریک لینچونی اومده: “توانایی مدیریت مکالمات دشوار می‌تونه به بهبود ارتباطات و کاهش سوءتفاهم‌ها کمک کنه.” این رو به تیم بگین که نوشتن متن در ارتباط باگ زیادی داره و اگه کسی ناراحت شد یا موردی رو بد برداشت کرد سریع ارتباط رو به تصویری تبدیل کنن (و خودکار بخش زیادی از مسئله‌ها حل میشه)همچنین، آموزش موانع درست #شنیدن هم از جنبه‌های مهم ارتباطاته. به قول دانیل گولمن در کتاب “Emotional Intelligence”: “توانایی شنیدن فعال و درک عمیق احساسات دیگران، کلید ایجاد ارتباطات مؤثر است.” 🧠 تله‌های شنیدن درست و فعال رو باید بدونید تا بتونید ذهن‌تون رو مدیریت و کنترل کنید.افزایش #هوش_هیجانی در این تیم‌ها هم خیلی حیاتی‌س. به نقل از گولمن: “هوش هیجانی به ما کمک می‌کنه تا احساسات خود و دیگران رو درک کنیم و در نتیجه ارتباطات بهتری برقرار کنیم.”در نهایت، رسیدگی سریع به #تعارضات در تیم‌های ریموت خیلی مهمه. به گفته موریس: “تعارضات کوچک که در تیم‌های حضوری ممکنه نادیده گرفته بشن، در تیم‌های ریموت می‌تونن به مشکلات جدی تبدیل بشن.” ⚠️پس با به کارگیری این روش‌ها و آموزش‌ها می‌تونی به بهبود ارتباطات و همکاری در تیم‌های ریموت کمک کنی و از بروز مشکلات جلوگیری کنی. به‌طور منظم چک‌این کن: تماس‌های ویدیویی هفتگی کمک می‌کنه تا پیشرفت رو پیگیری کنی، مشکلات رو حل کنی و ارتباطات تیمی رو قوی‌تر کنی. 🎥✨یادتون باشه که جلسات زیاد، در کار ریموت زیاد نیستن! شما تو کار حضوری هر روز و هر لحظه در ارتباط مستقیم و چهره به چهره با هم‌تیمی‌ها هستی، میتونید برید تو بالکن و گپ بزنید، میتونید بشینید پای یه سیستم و سریع یه چیزی رو چک کنید (و انگار هر لحظه تو میت هستین!) ولی اینجا این خبرها نیست پس باید با میت های مختلف این خلا رو پر کنی که اگه درست اینکار رو بکنی بهره‌وری بهتری هم داره

سادگی جوهر خوشبختی است

حسین دادخواه — Tue, 18 Feb 2025 12:00:56 +0330

https://aparat.com/v/aed0rg9 “سادگی جوهر خوشبختی است” سیدریک بلدوچرا اینطوریه؟ اصلا واقعا اینطوریه؟ 😀سادگی یعنی چی؟ #سادگی یعنی #زندگی کردن بدون دردسر، دوری از شلوغی‌ها و #تمرکز روی چیزهایی که واقعاً برای ما اهمیت دارن. این می‌تونه به معنای مرتب کردن فضای زندگی‌مون، انتخاب روابط معنی‌دار و کم کردن حواس‌پرتی‌ها باشه. وقتی زندگی‌مون رو ساده می‌کنیم، می‌تونیم به راحتی از چیزهایی که واقعاً برامون ارزشمند هستن لذت ببریم.رابطه سادگی با خوشبختی چیه؟ خوشبختی معمولاً توی رضایت و قدردانی از لحظه‌های حاله. وقتی زندگی‌مون رو ساده‌تر می‌کنیم، راحت‌تر می‌تونیم روی چیزهایی که به ما #شادی می‌دن تمرکز کنیم و #استرس و نگرانی‌هایی که از پیچیدگی‌ها به وجود میاد رو کم کنیم. اینطوری می‌تونیم بیشتر از لحظه‌ها لذت ببریم و به احساس #خوشبختی نزدیک‌تر بشیم.در واقع، سادگی کلیدیه برای یک زندگی شادتر و معنادارتر و متمرکز‌تر و همه‌اش یعنی باکیفیت‌ترچطوری سادگی رو در زندگی‌مون بیاریم؟فضا رو مرتب کن: چیزهایی که به درد نمی‌خورن یا خوشحالت نمی‌کنن رو دور بریز. این کار می‌تونه محیطی آرام‌تر برات بسازه.تعهدات رو محدود کن: به کارهایی که براتون مهم نیستن نه بگید و فقط روی چیزهایی که واقعاً براتون ارزش داره تمرکز کنید. (#اصل_گرایی)ذهن‌آگاهی تمرین کن: با کارهایی مثل #مدیتیشن یا نوشتن، به لحظه حال توجه کنید و ازش لذت ببرید.روابط رو تقویت کن: زمان بیشتری رو با کسایی که براتون مهمن بگذرونید و روابط عمیق‌تری بسازید.اهداف واضح تعیین کن: ببینید چه چیزهایی براتون واقعاً مهمه و اهدافی که با ارزش‌هاتون هم‌خوانی داره رو تعیین کنید و از حواس‌پرتی‌های اجتماعی دوری کنید.سادگی در توسعه نرم‌افزاراصل KISS (Keep It Simple, Stupid) یعنی چی؟ این اصل می‌گه که طراحی‌ها باید تا جایی که می‌شه ساده باشن. یه گزارش از IEEE نشون می‌ده پروژه‌هایی که به این اصل توجه می‌کنن، ۳۰ درصد کمتر با مشکلات جدی مواجه می‌شن و ۲۰ درصد هم #زمان کمتری برای #توسعه نیاز دارن. این آمارها نشون می‌ده که سادگی چطور می‌تونه پیچیدگی رو کم کنه و کارایی رو بالا ببره.سادگی و تجربه کاربری (UX)وقتی طراحی رابط کاربری (UI) ساده باشه، کاربران راحت‌تر می‌تونن با #نرم‌_افزار ارتباط برقرار کنن. طبق تحقیقی از Nielsen Norman Group، ۹۴ درصد از کاربران به طراحی‌های پیچیده و گیج‌کننده واکنش منفی نشون می‌دن. پس می‌بینید که سادگی چقدر می‌تونه روی رضایت کاربران تأثیر بذاره.کاهش هزینه‌ها و بازم سادگییه مطالعه از McKinsey نشون می‌ده پروژه‌های نرم‌افزاری که روی سادگی تمرکز دارن، می‌تونن تا ۴۰ درصد هزینه‌های توسعه رو کم کنن. این به خاطر اینه که نیاز به اصلاحات و تغییرات تو مراحل بعدی کمتر می‌شه.در مورد چابکی (#Agility) هم باید بگم که تو متدولوژی‌های چابک، سادگی خیلی مهمه. طبق گزارشی از Scrum Alliance، تیم‌های #چابک که روی سادگی تمرکز می‌کنن، ۲۵ درصد سریع‌تر از تیم‌های سنتی به نتایج می‌رسن. این یعنی سادگی می‌تونه روند توسعه رو تسریع کنه.نگهداریسادگی در کدنویسی یعنی نوشتن کدهای تمیز و قابل فهم. طبق تحقیقی از GitHub، پروژه‌هایی که از اصول کدنویسی ساده پیروی می‌کنن، ۵۰ درصد کمتر احتمال داره که در طول زمان با مشکلات نگهداری مواجه بشن. این به توسعه‌دهنده‌ها کمک می‌کنه که به راحتی کد رو تغییر بدن و بهبودش بدن.پس می‌بینید که سادگی تو دنیای نرم‌افزار چقدر می‌تونه مؤثر باشه!نظر شما چیه؟