Ditty | دیتی

۳۵۰ نکته برای داشتن فرانت‌اند با کیفیت 🚀 ـ Front-End Checklist که قبلاً فقط یک ریپوی گیت‌هاب و شامل چک‌لیست‌ها و نکات کاربردی برای داشتن برنامه‌های فرانت‌اند با کیفیت بود، حالا برای همون محتوا یک وبسایت ساخته و البته! MCP Server برای استفاده توسط ابزارهای AI! - این چک‌لیست شامل مواردی مثل پرفورمنس، تست، امنیت و سئو میشه: https://frontendchecklist.io @ditty_ir

همونایی که فقط یه مهندس نرم‌افزار می‌تونه ببینه 👀 این داستان یکی از بچه‌ها توی هلند هست برام جالب بود:

مدتی هست که بخاطر هوش مصنوعی فشار کار فنی کمتر شده، سعی می‌کنم از فرصت پیش‌اومده استفاده کنم و یکم از نقش خودم بالاتر برم و کارهایی بکنم که در سال‌های قبل از هوش مصنوعی اصلاً به ذهنم هم خطور نمی‌کرد و کسی هم انتظار نداشت انجام بدم. مثلاً به تیم‌های دیگه مثل تیم فروش و بازاریابی سر می‌زنم و می‌ببینم محصولی که ساختیم از دیدگاه اونها یا مشتری‌ها چطوریه و آیا کم و کاستی داره یا نه یکی از چیزهایی که جدیداً انجام دادم این بود که درخواست کردم دسترسی Search Console گوگل رو بهم بدن تا ببینم اپ توی سرچ گوگل وضعیتش چطوریه. و دیدم یه سری چیزها و آمارها بالا پایین هست 😄🙈 و گره‌های ریزی توی دشبرد وجود داره شاید از دید یک فرد غیر فنی پنهان بمونه. چیزهایی که وظیفه تیم فنی بود. این کار پیش‌دستانه باعث شد دست به کار بشم و چندین فیکس انجام بدم. از جمله بهبود سئو و سرعت برنامه. نکات ریزی که شاید بدون دخالت من به من منتقل نمی‌شد. تجربه‌ای که از این اتفاق گرفتم این بود که بعضی وقت‌ها چیزهایی که به چشم یه فرد فنی میاد رو تیم‌ها و افراد دیگه ندارن

اگه مهندس نرم‌افزار هستید سعی کنید از این نکته‌ها و فعالیت‌ها غافل نشین. اینطور که من بازار و تغییرات مشاغل رو می‌بینم، شغل مهندسی نرم‌افزار کم‌کم داره از حالت کلاسیک خودش که ۸۰٪ کدنویسی بود فاصله می‌گیره و فعالیت‌‌هایی فراتر از اون یعنی تعاملات انسانی توی اون داره پررنگ‌تر میشه یه مقاله هم جدیداً خوندم با عنوان «شغل‌های جدید مهندسی نرم‌افزار توی دوران هوش مصنوعی». یکی از این شغل‌ها که خیلی داره سر زبون‌ها میچرخه Forward Deployed Engineer هست که به مهندس نرم‌افزاری گفته میشه میره پیش مشتری‌ها، الگوهای پیدا و پنهان اون شرکت رو یاد بگیره (همونایی که فقط یه مهندس نرم‌افزار می‌تونه ببینه) و از این تجربه یه محصول قابل استفاده برای همه مشتری‌های فعلی و بعدی بسازه. خلاصه اینکه هیچ شغلی دائمی نیست. مخصوصاً شغل‌های مرتبط با تکنولوژی. همیشه آماده تغییر باشیم 🙂

🔺یه ابزار جالب هوش مصنوعی دیدم برای جستجوی شغل که این کارا رو انجام میده برات: - شغل‌ها رو جستجو می‌کنه - رزومه‌ات رو برای شغل مد نظر شخصی‌سازی می‌کنه - کاورلتر می‌نویسه - برای مصاحبه آماده‌ت می‌کنه https://github.com/MadsLorentzen/ai-job-search ۴۳هزار استار و ۱۵هزار فورک داره. یاد یه چیزی افتادم. بارها پیش اومده که رزومه‌ها رو بررسی کنم. رزومه‌هایی که رنگ و بوی هوش مصنوعی میداد راستش واسم جالب نبود. نه اینکه بدم بیاد، بلکه فکر می‌کردم با این رزومه نمیشه سطح طرف رو متوجه شد و ارزش‌گذاری کرد. و بنابراین از راه‌های دیگه تلاش می‌کردم واقعاً ببینم طرف چکارست. به نظرم این روش‌ها و ابزارها فقط شاید توی کوتاه مدت جواب باشه. تصور کنید استفاده از این ابزارها بیشتر فراگیر بشه و همهٔ رزومه‌ها و کاورلترها به دست هوش مصنوعی نوشته بشه. همه رزومه‌ها خوشگل و شیک و پر از کلمه‌ها و جمله‌های سنگین و رنگین. دیگه کم‌کم بررسی رزومه و کاورلتر با انسان و ATS کار بی‌ارزشی میشه، و ملاک‌ها و معیارهایی جز یه نوشتهٔ دو صفحه‌ای (=رزومه) برای بررسی سطح کاندیداها مهم‌تر میشن. مثل فعالیت‌های شبکه‌های اجتماعی، نظر کارفرماهای قبلی درباره مهارت‌های ارتباطی و کار تیمی. یعنی شاید چیزهایی که خارج از رزومه باقی می‌ذاریم @ditty_ir

🔺کد درست، توی جای نادرست • روی دو تا پروژه کار می‌کنم. اولی (پروژه شرکت) تقریباً خط به خط و فایل به فایلش رو می‌شناسم. دومی (پروژه شخصی تفریحی) هم کلاً از اول وایب‌کد شده و هیچ تصوری از فایل‌ها و کدهاش ندارم • نکته جالبی متوجه شدم اینکه وقتی از Claude می‌خوام تغییراتی توی پروژه‌ها بده، توی پروژه‌ای که روش تسلط دارم معمولاً چند بار پیش میاد که پیشنهادهای اون رو رد کنم، اصلاح کنم و بهش کانتکست بدم و بگم کلاود جان، این چیزی که دادی به فلان دلیل بهتره اینطوری نوشته بشه، یا اصلاً نوشته نشه • مثلاً کامپوننت جدید می‌سازه، بهش می‌گم کامپوننت رو درحال حاضر داریم، و میگه ایول این یکی حتی بهتر هم هست. یا تست می‌نویسه ولی توی فایل جدید. بهش میگم تست‌های مشابه در حال حاضر توی فلان فایل هستن. میگه آره راست میگی اونجا جای بهتری هست. حتی گاهی اوقات جلوتر میره و فیچرهای اضافه‌تر می‌نویسه. ولی بهش میگم اینها تصمیم من نیست، بلکه بیزینس باید تصمیم بگیره. • اما برعکس، توی پروژه وایب‌کد شده چونکه هیچ تصوری از کدها و فایل‌ها ندارم، هر چیزی که کلاود میگه رو قبول می‌کنم • حالا تصور کنید اگه پروژه شرکتی سطح بالا باشه و توسعه‌دهنده‌های اون همه وایب‌کدر. می‌تونید تصور کنید بعد از یک‌سال چه حجم عظیمی از کدهای اسپاگتی توی پروژه جمع میشه؟ کدهایی به ظاهر شیک و تمیز ولی همه پوشالی و جنگلی، که توسعهٔ اون دیگه از کنترل انسان خارجه و فقط باید بسپاریش به خدا و بعد هوش مصنوعی 😄 @ditty_ir

توی دوره هوش مصنوعی چطوری یک مهندس نرم‌افزار با ارزش باشیم؟ - یکی از دوستام ‌که شخص فنی‌ای نیست می‌گفت با Claude یه اپ ساخته و ماهی بیشتر از ۴۰۰۰ کامیت انجام میده! نمی‌دونم این کار رو خودش انجام میده یا کلاود. ولی واسه همین روی گیت‌هاب به محدودیت خورده. تمام مدت فعالیتم هیچوقت چنین تعداد کامیت ماهیانه رو نشنیده بودم، اون هم تک‌نفره، و جالب‌تر، اون هم توسط یک آدم غیر فنی! - حالا فارغ از اینکه چکار و چطوری کار می‌کرد، این اتفاق من رو به فکر وا داشت: الان که نوشتن کد خیلی راحت و ارزون شده، پس چه چیزی گرون و با ارزش شده؟ یا چه چیزی همچنان با ارزش مونده؟ اگه یه چیزی ارزون میشه پس حتماً باید جای دیگه‌ای چیزی دیگه‌ای گرون شده باشه. آیا اون دوست من واقعاً هزینه‌ش پایین اومده؟ یا اینکه هزینه رو منتقل کرده به یه جای دیگه؟ - اگه هوش مصنوعی یه کد که انسان توی ۱ماه می‌نویسه رو توی ۱ ساعت بنویسه و اگه این کد خطا داشته باشه یا مطابق انتظار کسب‌وکار خروجی نداشته باشه، مسئولیتش با کیه؟ آیا میشه هوش مصنوعی رو سرزنش کرد؟ آیا میشه از هوش مصنوعی درخواست غرامت کرد؟ به نظرم خیر، اما از شخصی که مسئول این کد بوده حتماً! شخصی که بدونه چه کدی خوبه چه کدی بد، چه کدی باید تأیید بشه چه کدی نه، چه کدی سودآوری داره برای شرکت و چه کدی نه، همچنان شخصی با ارزش هست. پس اینجا «پذیرفتن مسئولیت» گرون و با ارزش میشه - به نظرم کسی توی این دوره همچنان با ارزش و گرون باقی می‌مونه که بتونه هم از کد سر در بیاره و هم از کسب و کار. از لحاظ فنی یکی از با ارزش‌ترین مهارت‌های این دوره مهارت «دیباگ کردن» و «فهم کد» هست. یعنی شما بدونی کدی که هوش مصنوعی نوشته چیه - شاید بگید که خب هوش مصنوعی هم می‌تونه دیباگ کنه، از یک انسان بهتر. درست. اما حتی اگه هوش مصنوعی ۱۰ بار هم روی یک کد، کد ریویو انجام بده، نهایتاً مسئولیت قبول یا رد این کد با یک انسان هست. و ما نمی‌تونیم هوش مصنوعی رو مسئول نتایجش بدونیم. پس کسی که می‌تونه زیر این کد رو امضا کنه، حتماً باید صفر تا صد عواقب اون رو هم بپذیره - نکته جالب اینجاست که این مهارت‌ها (دیباگ کردن و فهم کد در جهت کسب‌وکار) مهارت‌هایی هستن که روز به روز کمیاب‌تر و گرون‌تر میشن. بخاطر وابستگی به هوش‌مصنوعی - پس توی دنیایی که همه به‌سرعت خروجی میدن، کسی که بشه بهش اعتماد و گفت «فلانی گفته این کد خوبه، پس خوبه» یکی از با ارزش‌ترین دارایی‌هاست که یه مهندس نرم‌افزار می‌تونه داشته باشه https://ditty.ir/posts/ai-coding-value-skills-responsibility/913695287955

هوش مصنوعی یک سازمان خوب رو خوب‌تر، و یک سازمان بد رو بدتر می‌کنه یه قسمتی از یه مقاله خیلی برام جالب بود، که می‌گفت هوش مصنوعی صرفاً یه آمپلی‌فایر و تقویت‌کننده هست. یعنی یک شخص، تیم یا مجموعه با پایه‌های قوی و فرهنگ خوب می‌تونه به واسطهٔ هوش مصنوعی چندین برابر بهتر بشه و رشد کنه. و بلعکس: هر چیزی که توی یک سازمان آشفته وجود داره با هوش مصنوعی می‌تونه بدتر بشه. هوش مصنوعی به قول خودمون یک شمشیر دولبه هست. اگه مثل هر ابزار دیگه‌ای کار ما رو بهتر کرده، اونجا نقطه قوت ماست. و بلعکس. نظر شما چیه؟ توی شرکت شما هوش مصنوعی کار رو بهتر کرده یا بدتر؟ کاری که قبلاً بدون هوش مصنوعی انجام می‌دادین، با اومدنش بهتر انجامش میدین؟ یا نه؟

سخت‌ترین قسمت مصاحبه‌های من توی چند سال گذشته بیشتر از ۲۰۰ مصاحبهٔ فنی و غیر فنی داشتم. طبق تجربهٔ من، سخت‌ترین قسمت هر مصاحبه دقایق ابتدایی مصاحبه بوده. یعنی جاهایی که تأثیرگذاری اولیه یا به قول معروف First Impression اتفاق میوفته. یعنی جایی که وارد تماس میشی، سلام علیک می‌کنی و مهمتر، جایی که میگن «خب، حالا خودت رو معرفی کن». اگه حس کنم که این قسمت رو به‌خوبی پشت سر گذاشتم، معمولاً ادامهٔ مصاحبه رو با اعتماد به نفس بیشتری می‌تونم پیش ببرم. حتی جواب دادن به سوالات فنی هم خیلی راحت‌تر میشه. حتی اثرگذاری جواب‌های غلط هم کمتر میشه 😃 درباره این تجربه اینجا بیشتر توضیح دادم: https://ditty.ir/p/PyT5V برای شما سخت‌ترین قسمت مصاحبه‌ها کجاست؟ بگید تا با تجربه‌های هم بیشتر آشنا بشیم.

اصطلاح TL;DR رو احتمالاً شنیده باشین: یعنی Too long; Didn’t Read یا «خیلی طولانی بود، نخوندمش» و معمولاً آدما زمانی این رو میگن که حوصلهٔ خوندن یک متن طولانی رو ندارن. حالا یه اصطلاح جدید دیدم به اسم AI;DR یعنی «متن هوش مصنوعی بود، نخوندمش» 😄 یعنی وقتی که طرف حتی حوصله نداشته که متن هوش مصنوعی رو یه ویرایش ریز کنه، آدما زیاد هم حوصله ندارن بخوننش به نظرم ماشینی شدن هر چیزی قشنگ نیست. مخصوصاً گفت‌وگوهای یک به یک با یه انسان دیگه. من به شخصه توی تعامل‌های انسانی سعی می‌کنم از ادبیات خودم استفاده کنم. مخصوصاً توی رزومه و فرایند استخدام. یکی از علت‌های رد شدن رزومه‌ها یا جواب نگرفتن ایمیل همین می‌تونه باشه. یعنی کل رزومه و ایمیل و کاورلتر بوی هوش مصنوعی میده. و منابع انسانی هم به خودش میگه «من با هوش مصنوعی طرف هستم یا انسان؟»

کار فنی عالی 👍 مهارت‌های تیمی خالی 👎 • یه هم‌تیمی داشتیم که توی کارهای فنی خیلی قوی بود، ولی ذهنیتی که داشت اصلاً بدرد تیم ما (و احتمالاً هر تیم دیگه‌ای) نخورد و نهایتاً از شرکت رفت. در واقع توی زمینه‌ای خبره بود که امروز هوش مصنوعی توش خبره هست! • این همکار ما زیاد از محصول اطلاعاتی نداشت، نمی‌دونست چه سوالاتی بپرسه و کلاً انگار نمی‌دونست برای چی استخدام شده. مثلاً جایی که انتظار داشتیم بپرسه و نقد کنه که «به نظر شما این ویژگی بدرد چند تا از کاربرا می‌خوره»، می‌پرسید که «این رو با جاوا بزنیم یا پایتون؟». و این شد نقطه ضعف جدی اون • وقتی دامنه کسب و کار رو نمی‌دونی ناخواسته منزوی میشی. مثل ورزشکاری که تکنیک‌های فردی خیلی خوبی داره، ولی اصلاً نمیدونه توی تیم داره چکار کنه. بدون که تیمت داره چکار می‌کنه. بدون که شرکتت داره چکار می‌کنه و به چه سمتی میره. یه هم‌تیمی خوب در خدمت کل تیم هست! • پرسیدن سوال فنی بد نیست. اما بجای خودش. این مهارتی هست که ایرانی‌ها باید بیشتر بهش توجه کنن. شما توی شرکتتون بیشتر چه نوع سوالاتی می‌پرسید؟ راستی این تجربه رو از دیتی هم می‌تونی بخونی: https://ditty.ir/posts/soft-skills-senior-developer-lesson/596593518521 #teamwork

وقتی کلاود کدی رو که خودش نوشته بود ریویو کرد و بعد رجکتش کرد این روزها بخش زیادی از کدها برای برنامه‌هایی که اهمیت زیادی ندارن رو می‌سپارم به کلاود. و اونهایی که حساس‌تر هستن رو خودم سعی می‌کنم بیشتر دخالت کنم و درگیر بشم (که این هم از تجربیاتی بدست اومده که بعداً علتشو به اشتراک میذارم) و اینکه برای خودم یک Skill کلاود برای کد ریویو ساختم، که آدرس Pull Request رو می‌گیره و ریویو انجام میده و خروجی و نکات اون رو به دسته‌بندی‌های Blocker و High و Medium و … تقسیم‌بندی می‌کنه و میفرسته. Blocker یعنی مثلاً این کد اصلاً نباید مرج بشه. High هم مثلاً یعنی باگ بزرگی دیده میشه چیزی که برای من خیلی جالب بود اینه که وقتی از این Skill روی یک Pull Request که اون هم کاملاً با کلاود نوشته شده استفاده کردم، ۳ تا مشکل High و ۵ تا Medium پیدا کرد. بماند که گاهی اوقات بلاکر هم پیدا می‌کنه! یعنی کلاود میاد کدی که خود کلاود نوشته رو ریویو می‌کنه، ازش چند تا مشکل در میاره و گزارش میده! اینکه این مسئله به وجود میاد علت‌های مختلفی داره. همش هم تقصیر کلاود نیست. بخشی از اون برمی‌گرده به نحوهٔ استفاده از هوش مصنوعی و کانتکستی که بهش میدیم. خلاصه اینکه مشکل هم می‌تونه به کلاود برگرده و هم به برنامه‌نویس. به نظرتون چرا؟

🔺این پروژه دیپ‌سیک توی یک هفته ۱۴۹هزار استار گرفته توی گیت‌هاب 👀 • اگه بخوام یه توضیح کوتاه بدم، پروژهٔ Deepseek Harness یه جورایی رقیب Claude Code و Codex هست، ولی اوپن‌سورس اطلاعات بیشتر: https://news.ditty.ir/BMALP @ditty_ir

🔺قابلیتی که یک ماه بعد از انتشار به دست مشتری رسید • توی یکی از پروژه‌ها یک قابلیت جدید منتشر کرده بودیم. ولی دیدیم که این قابلیت به دست خیلی از کاربرا نرسیده و کاربرا دارن هنوز از نسخه قدیمی استفاده می‌کنن. بعد از کلی بررسی متوجه شدیم که مشکل از کجا بود ← کش مرورگر کاربر 😬 • خلاصه اینکه تلاش کردیم با روش‌هایی مشکل کش مرورگر کاربر رو حل کنیم. و هزینه‌ای که دادیم این بود که حدود ۱ ماه باید صبر می‌کردیم تا همه کاربرا کش مرورگرشون پاک بشه. چون از روش‌های رایج این مشکل قابل رفع نبود • راه حل، استفاده از یک هدر HTTP بود. هدری که سال‌های سال باهاش آشنا بودم و چند باری هم اختصاصی تلاش کرده بودم یادش بگیرم، ولی توی این تجربه انگار چنین چیزی رو اصلاً ندیده بودم! که یک درس و تجربه دوباره برام زنده شد ← آدمیزاد به‌واسطه «تجربه کردن» واقعاً یاد می‌گیره، نه با روش‌های تئوری همچنین نکتهٔ فنی که از این تجربه یاد گرفتم تا همیشه به یادم موند. جزییات فنی این تجربه رو اینجا نوشتم: چطوری no-cache رو واقعاً یاد گرفتم • خلاصه اینکه ذهن ما خوب بلده که چیزهایی که لازم نداریم رو بندازه بیرون. اگه هزاران کتاب درباره نقاشی بخونیم، تا وقتی که دست به قلم نشیم، فایده‌ای نداره. پس سعی کنیم هر چیزی که قصد یادگیری اون رو داریم رو گره بزنیم به «یک کار واقعی یا عملی». مثلاً نگید می‌خوام جاوااسکریپت یاد بگیرم. یک پروژه واقعی رو با جاوااسکریپت پیاده‌سازی کنین. توی یک کار و پروژه واقعی بعضی وقت‌ها حتی چیزهایی رو یاد می‌گیریم که اصلاً فکرش رو نمی‌کردیم که باید یاد بگیریم. من به این روش میگم «یادگیری ناخواسته» 😄 • شما هم تجربه مشابهی از یادگیری تئوری و یادگیری توی عمل دارین؟ @ditty_ir

‏OSV: پایگاه دادهٔ توزیع‌شدهٔ آسیب‌پذیری متن‌باز ‏OSV.dev یه پایگاه دادهٔ باز و توزیع‌شده از آسیب‌پذیری‌های متن‌بازه که با فرمت استاندارد OSV و یه API و اسکنر، آسیب‌پذیری‌ها رو دقیق به نسخهٔ پکیج یا کامیت وصل می‌کنه.

روی یک پروژه فرانت‌اندی Monorepo که خیلی سنگین شده بود کار می‌کردیم، و دستور npm audit حدود ۴۰ دقیقه طول می‌کشید تا جواب بده! با osv.dev این ۴۰ دقیقه شد ۲ ثانیه! 👇

استک اورفلو یه پلتفرم API محور راه انداخته که توش ایجنت‌های کدنویس به‌جای آدما دانش به اشتراک می‌ذارن، ولی همچنان یه آدم باید قبل انتشار تأیید کنه: https://news.ditty.ir/DES1I

‏آیا AI کتاب‌های آموزشی رو کشته؟ ‏تیم فریس آمار فروش پنج کتاب پرفروششو رو می‌کنه تا نشون بده از وقتی چت‌بات‌ها اومدن، فروش کتاب‌های «چطور انجام بدم» چطوری ریزش کرده.

‏وقتی LLMها ستون‌های تخصص یه مهندس رو می‌ریزن ‏یه مهندس با ده سال سابقه می‌نویسه چطور هوش مصنوعی یکی‌یکی ستون‌های تخصصش رو ریخته و حالا نمی‌دونه برای آینده‌ش چی کار کنه: 👇 news.ditty.ir/BHeU2

‏در بازار کار از «درهای جانبی» وارد شو ‏بازار کار شلوغ‌تر از همیشه‌ست، اما همه‌ی فرصت‌ها از طریق آگهی‌های شغلی نمی‌رسن. گاهی یه ایمیل به‌جا یا یه مقاله‌ی عمومی می‌تونه در بسته‌ای رو باز کنه.

‏اوبر بعد از این‌که کل بودجهٔ هوش مصنوعیِ ۲۰۲۶ رو تو چهار ماه سوزوند، برای هر کارمند سقفِ ماهیانهٔ مشخصی روی هر ابزار کدنویسیِ ایجنتیک گذاشت: https://news.ditty.ir/FsRyn