بیایم در مورد یه واقعیت تلخ ولی خیلی مهم توی دنیای توسعه نرم‌افزار صحبت کنیم:

فرق بین یه هفته سختِ معمولی با زندگی توی حالت همیشه بحرانی!

​توی شغل ما قطعاً پیش میاد که سرورها زمین بخورن، باگ‌های دقیقه نودی سر برسن یا کلاً اولویت‌های اسپرینت به خاطر یه وابستگیِ غیرمنتظره به هم بریزه.

این چیزها بخش طبیعیِ کار ماست و نمیشه کلاً حذفشون کرد. اما مشکل اصلی از جایی شروع میشه که «بحران» بشه روتینِ روزمره‌مون!

​وقتی تمام ددلاین‌ها «حیاتی» بشن، همه باگ‌ها اولویت اول باشن و هر هفته شبیه به یه میدان جنگ باشه، تیم‌ها کم‌کم حس حساسیتشونو از دست میدن و این وضعیت رو به عنوان «واقعیت کار» می‌پذیرن.

​اما این حالت آتش‌نشانیِ همیشگی، یه هزینه مخفی و سنگین داره:

​تیم‌ها به جای برنامه‌ریزی آینده، فقط جلوی پاشون رو می‌بینن و واکنشی رفتار می‌کنن.


​تمام انرژی مهندس‌ها صرف حل کردن مشکلات امروز میشه، در حالی که دقیقاً همون مشکل ماه بعد دوباره تکرار میشه!

​هر وقت دیدین توی چنین چرخه‌ای گیر کردین، به جای اینکه بیشتر فشار بیارین، یه قدم بیاین عقب و این سوالات کلیدی رو از خودتون و تیم بپرسین:

​چرا این موضوع یهو انقدر اضطراری شد؟
​آیا می‌شد جلوی وقوعش رو گرفت؟
​داریم ریشه مشکل رو حل می‌کنیم یا فقط صورت‌مسأله رو پاک می‌کنیم؟
​این هفته یه استثنا بود یا مدل کاریِ همیشگی ما همینه؟

​بهترین تیم‌های مهندسی اونایی نیستن که هیچ‌قت هفته سخت ندارن، بلکه اونایی هستن که با اتوماسیون، مستندسازی دقیق، تست‌های درست و برنامه‌ریزی واقع‌بینانه، کاری می‌کنن که نیاز به «قهرمان‌بازی» روز به روز کمتر بشه.

دقت کنین که ​شلوغیِ گاه‌وبیگاه اجتناب‌ناپذیره، اما زندگی در حالت آتش‌نشانیِ دائمی اصلاً منطقی نیست!

​
#مهندسی_نرم_افزار
#مدیریت_تیم

#SoftwareEngineering
#TechLeadership
#EngineeringCulture

میخام در مورد یه هکِ فکری عالی صحبت کنیم که شیوه کار مهندس‌های خفن رو کلاً زیر و رو می‌کنه!

توی نگاه اول ممکنه متناقض به نظر برسه، اما بهترین برنامه‌نویس‌هایی که تا حالا دیدم، موقع شروع کار جدید کندتر از بقیه عمل می‌کنن.

این افراد به محض اینکه یه فیچر یا نیازمندیِ جدید دستشون می‌رسه، سریع کامپیوتر رو باز نمی‌کنن که شروع کنن به کد زدن. اول کار:
شروع می‌کنن به سوال پرسیدن و صورت‌مسئله رو چالش می‌کشن.

تموم سناریوهای خاص و حالت‌های لبه‌ای  رو حساب می‌کشن.

قبل از اینکه شیرجه بزنن توی کد و معماری فنی، اول منطقِ اون مشکلِ کسب‌وکار رو خوب هضم می‌کنن.

این فرایند شاید در ظاهر کندتر به نظر برسه، اما وقتی مقایسه‌ش می‌کنی با کسی که سریع و بی‌فکر شروع کرده به کد زدن و حالا باید دو هفته تمام باگ بگیره و نصف کدها رو از اول بازنویسی کنه، تازه می‌فهمی کی سریع‌تر بوده!

تجربه لزوماً سرعتِ دست به کد شدنت رو بالا نمی‌بره؛ فقط اون‌قدر بهت مکث میده که توی مسیر اشتباهی ندوئی.

تفکر عمیق و آروم، همیشه تهش به یه خروجیِ سریع و تمیز می‌رسه.

جالبیش اینجاست که این درس فقط برای برنامه‌نویسی نیست.

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

#مهندسی_نرم_افزار
#تجربه_کاری
#برنامه_نویسی
#توسعه_فردی

#SoftwareEngineering
#Productivity
#MindfulCoding
#SeniorDeveloper

حقوق اولت، سقف درآمد آینده‌ت رو تعیین نمی‌کنه!

خیلی از مهندس‌ها کارشون رو با حقوق‌های خیلی معمولی شروع می‌کنن اما چند سال بعد به درآمدهای فوق‌العاده بالا می‌رسن. این جهش ربطی به هوش خدادادی نداره.

نتیجه سرمایه‌گذاری مداوم روی خودته، دقیقاً وقتی که بقیه توی منطقه امنشون جا خوش کردن!

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

رشد شغلی یه شبه اتفاق نمی‌افته، ولی اثر مرکبش غوغا می‌کنه.

شما برای رشد امسالتون چه برنامه‌ای دارین؟

#رشد_شغلی
#توسعه_فردی
#برنامه‌نویسی
#CareerGrowth
#SoftwareEngineering
#Mindset

یه واقعیت تلخ توی دنیای توسعه وجود داره: ۹۰٪ از ما داریم  عمل می‌کنیم، نه فکر می‌کنیم.

می‌بینی که  داکر فایل نوشته:

FROM ubuntu

برای یه web app ساده. در حالی که می‌تونست روی Alpine یا مشابهش باشه و بیست برابر سبک‌تر.

این فقط یه اشتباه فنی نیست؛ یه نشونه از فقدان تفکر انتقادی‌ست. وقتی حجم بیست برابر می‌شه، هزینه‌ی انتقال، زمان deploy، و سطح حمله هم همین‌قدر بزرگ‌تر می‌شن.

ما داریم با ابزارهای مدرن، روش‌های قدیمی رو تکرار می‌کنیم. سرعت بالا رفته، اما دقت پایین اومده.

هوش مصنوعی می‌تونه کد بنویسه، ولی تصمیم‌گیری رو نه. انتخاب پایه‌ی درست،  کار انسانه.

آیا ما داریم توسعه‌دهنده می‌شیم یا فقط کپی‌کننده؟

#هوش_مصنوعی
#مهندسی_نرم‌افزار
#Docker
#DevOps
#AI
#SoftwareEngineering
#CloudComputing
#CriticalThinking

دوستان مدتی هست که بین برنامه‌نویس‌ها یک سوال زیاد مطرح میشه:

کلاد کد بهتره یا کرسر؟

اما نکته‌ای که بعد از کار با این ابزارها متوجه میشیم اینه که این دو ابزار دقیقاً برای یک هدف ساخته نشدن.

کرسر بیشتر یک محیط توسعه مجهز به هوش مصنوعی هست.

یعنی همون محیط کدنویسی آشنا رو داریم، اما با قابلیت‌هایی مثل پیشنهاد کد، ویرایش مستقیم و تعامل سریع با Ai

اما Claude Code بیشتر شبیه یک Agent در ترمینال عمل می‌کنه.

به جای اینکه فقط کنار دست شما کد پیشنهاد بده، میتونه یک تسک کامل را بررسی کنه، فایل‌های مختلف پروژه را تغییر بده و روی یک workflow چندمرحله‌ای کار کنه.

تجربه من اینه:

برای کارهای روزمره مثل:
✅ نوشتن کامپوننت
✅ اصلاح سریع کد
✅ اتوکامپلیت
✅ تغییرات کوچک در پروژه

کرسر خیلی تجربه روانی رو میده ولی زود به ملکوت میره

اما برای کارهایی مثل:
✅ ریفکتور کردن یک پروژه بزرگ
✅ بررسی چندین فایل
✅ تغییر معماری پروژه
✅ انجام taskهای چندمرحله‌ای

کلاد کد بیشتر شبیه یک همکار برنامه‌نویس عمل می‌کنه.

در واقع سوال درست این نیست که:
کدوم بهتره؟

سوال بهتر این هست:

من برای چه نوع کاری به AI نیاز دارم؟

#هوش_مصنوعی
#توسعه_نرم_افزار
#AI
#ClaudeCode
#Cursor
#AIAgent
#SoftwareEngineering

یه چیزی که بعد از کار کردن زیاد با Claude فهمیدم اینه که خیلی وقت‌ها مشکل از خود AI نیست، مشکل از مدل استفاده کردن ماست.

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

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

ولی برای یه ایده جدید، بهتره یه Chat تازه باز کنی تا ذهن مدل با اطلاعات قبلی شلوغ نشه.

یه نکته دیگه:
به جای اینکه فقط توضیح بدی چی می‌خوای، نمونه بده.
مثلاً یه اسکرین‌شات از یه سایت، یه طراحی روی کاغذ یا یه نمونه کار.

خیلی وقت‌ها یک تصویر بهتر از چند پاراگراف توضیح منظور رو منتقل می‌کنه.
یه اشتباه رایج هم اینه که وقتی AI جواب بد میده، همونجا می‌گیم:
نه اشتباهه!

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

اگر اطلاعات کافی نداری اول سوال بپرس.
این باعث میشه کمتر حدس بزنه و جواب دقیق‌تری بده.
و دقت کنین Claude Code هم فقط برای کدنویسی نیست.
قدرت اصلیش اینه که می‌تونه داخل Workflow شما قرار بگیره؛ پروژه رو بفهمه، تغییر بده، بررسی کنه و مثل یک Agent کمک کنه.

در نهایت فکر می‌کنم آینده کار با AI این نیست که فقط Promptهای عجیب و طولانی بنویسیم.
باید یاد بگیریم:
باید contex درست بدیم
مسئله رو درست تعریف کنیم
به Agent مسیر بدیم
و خروجی رو بررسی کنیم

هوش مصنوعی قوی بدون روش استفاده درست، فقط یه ابزار معمولیه.

#AI
#Claude
#ClaudeCode
#AIAgents
#LLM
#GenerativeAI
#SoftwareEngineering
#Productivity

چند وقتیه گزارش جدید Anthropic در مورد ساخت ایجنت‌های هوش مصنوعی رو دقیق خوندم. برخلاف خیلی از محتواهای تبلیغاتی که این روزها می‌بینیم، این یکی واقعاً کاربردی و مهندسیه. بر اساس تجربه‌های واقعی نوشته شده، نه شعار صرفا
و با دقت بخونید ببینید چه مواردی در مورد شون صحبت شده.

نکته مهم اینه که اصولش فقط مخصوص Claude نیست. می‌تونی همون الگوها رو روی Codex، Aider، Cursor یا practically هر coding agent دیگه‌ای هم پیاده کنی.

چند تا نکته کلیدی که به نظرم ارزشش رو داره جدی گرفته بشه:

طراحی ایجنت فقط پرامپت‌نویسی نیست.
باید workflow ساختاریافته بسازی؛ جایی که ایجنت بتونه فکر کنه، اقدام کنه، نتیجه رو بررسی کنه، دوباره تلاش کنه و در صورت نیاز موضوع رو escalate کنه. ایجنت‌ها بیشتر شبیه کامپوننت نرم‌افزاری‌ان تا یه تابع ساده.

حافظه یه موضوع معماریه، نه یه قابلیت فرعی.
نحوه مدیریت و انتقال context تعیین می‌کنه ایجنت چقدر مفید باشه. خلاصه‌سازی هوشمند، فایل‌های ساخت‌یافته و بازیابی محدود معمولاً خیلی بهتر از ریختن کل پروژه داخل پرامپت عمل می‌کنه.

برنامه‌ریزی اختیاری نیست.
برای مسائل چندمرحله‌ای نمی‌تونی انتظار داشته باشی مدل خودش همه‌چیز رو درست جلو ببره. الگوهایی مثل plan → execute → review یا reflection ساختاریافته واقعاً لازم‌ان و روی همه مدل‌ها جواب می‌دن.

ایجنت واقعی به ابزار واقعی نیاز داره.
دسترسی به shell، Git، API و ابزارهای اجرایی. ایجنتی که فقط توضیح می‌ده و اجرا نمی‌کنه، در محیط واقعی محدود می‌مونه.

خودمختاری نباید به هرج‌ومرج تبدیل بشه.
ایجنت‌های خودمختار می‌تونن سریع آسیب بزنن. باید محدوده مشخص، مرز و رفتار fallback تعریف کنی. خودمختاری کنترل‌شده خیلی بهتر از retryهای بی‌هدف عمل می‌کنه.

ارزش اصلی در orchestration.
یه ایجنت خوب فقط wrapper دور یه مدل زبانی نیست. هماهنگ‌کننده منطقه، حافظه، ابزارها و بازخورد. وقتی به سمت multi-agent می‌ری، این هماهنگی تقریباً همه‌چیز می‌شه.

در کل، این گزارش بیشتر از اینکه یه سند بازاریابی باشه، یه نقشه راه عملیه برای تیم‌هایی که می‌خوان ایجنت واقعاً کارآمد بسازن. اگر در حال ساخت یا ارزیابی coding agent هستید، خوندنش ارزشش رو داره.

#هوش_مصنوعی
#ایجنت_هوش_مصنوعی
#مهندسی_نرم_افزار

#Anthropic
#AIAgents
#AgenticAI
#LLM
#SoftwareEngineering

یک بار برای همیشه بگم دوستان
بعضی از دوستان خیلی نگرانند و استرس دارند .
چند سال پیش برنامه‌نویس خط به خط کد می‌نوشت تا پروژه جلو بره. امروز هم همون پروژه جلو میره، با این تفاوت که به جای دست به کیبورد بودنِ مداوم، داره یک ایجنت رو هدایت می‌کنه تا بخش اعظم کدنویسی رو انجام بده.

در واقع نقش برنامه‌نویس از «تایپیست کد» به «هدایت‌کننده سیستم» تغییر کرده.

وقتی خودرو اختراع شد، خیلی‌ها فکر می‌کردند دوران اسب تمام شده. اما واقعیت این بود که هدف انسان جابه‌جایی بود، نه خودِ اسب. با آمدن ماشین، نیاز از بین نرفت؛ ابزار بهینه‌تر شد.

امروز هم کسب‌وکارها دنبال «کد» نیستند، بلکه دنبال «حل مسئله» می‌گردند. کد فقط یک ابزاره. حتی الگوی مصاحبه‌ها هم داره تغییر می‌کنه؛ سؤال اینه که چقدر می‌تونی با ابزارهای AI مسئله‌های پیچیده الگوریتمی و معماری رو سریع‌تر حل کنی؟

اگر فردا هوش مصنوعی ۹۰ درصد کد رو بنویسه، باز هم یک نفر باید مشخص کنه دقیقاً چی باید ساخته بشه، چه معماری‌ای مناسبه، چه Trade-offهایی وجود داره و امنیت و مقیاس‌پذیری چطور مدیریت بشن.

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

از طرفی، شاید قبلاً برای ساخت یک محصول به ۱۰ برنامه‌نویس نیاز بود و حالا همون کار با ۳ نفر انجام بشه. خیلی‌ها این رو تهدید می‌بینند، اما معنیش کاهش شدید هزینه ساخت نرم‌افزاره.

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

آینده برنامه‌نویسی، حذف برنامه‌نویس نیست؛ تغییر نقش اونه.

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

یادتون باشه وایب کدینگ برای تست کردن ایده‌ها و ساخت ابزارهای سریع فوق‌العاده‌ست. اما وقتی می‌خواید سیستمی بسازید که ماه‌ها و سال‌ها کار کنه، نمی‌تونید اصالت مهندسی رو فدای سرعتِ ظاهری کنید.

#SoftwareEngineering
#Architecture
#AI
#DeveloperLife
#TechTrends

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

لینوس توروالدز اومده اولین نسخه آزمایشی هسته لینوکس ۷.۳ رو منتشر کرده و یکی از تغییرات مهمی که داخلشه، پشتیبانی اولیه از یو‌اس‌بی ۴ و تاندربولت روی تراشه‌های ام ۱ تا ام ۳ اپله.

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

البته نسخه آزمایشی اول به معنی انتشار نسخه نهایی نیست. این مرحله بیشتر نشون می‌ده تغییرات اصلی وارد شاخه انتشار شدن و از اینجا چند هفته آزمایش و رفع مشکل باقی می‌مونه تا نسخه نهایی لینوکس ۷.۳ احتمالاً حوالی اواسط تا اواخر اکتبر منتشر بشه.

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

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

#Linux
#LinuxKernel
#AppleSilicon
#AsahiLinux
#Thunderbolt
#USB4
#OpenSource
#ReverseEngineering
#KernelDevelopment
#LinuxDevelopment
#Apple
#M1
#M2
#M3
#SoftwareEngineering
#Technology

سازنده PostgreSQL یه جمله جالب درباره رقیب قدیمی این دیتابیس گفته. مایکل استون‌بریکر، خالق PostgreSQL، معتقده بخشی از محبوبیت امروز PostgreSQL رو باید مدیون Oracle بود.

ماجرا برمی‌گرده به سال ۲۰۱۰، زمانی که Oracle شرکت Sun Microsystems رو خرید و MySQL هم وارد مجموعه Oracle شد. همین اتفاق باعث شد خیلی از توسعه‌دهنده‌ها نسبت به آینده MySQL نگران بشن و بعضی‌ها حتی قبل از اینکه اتفاق خاصی برای پروژه بیفته، شروع به بررسی و مهاجرت به گزینه‌های دیگه کنن.

به گفته استون‌بریکر، همین ترس یکی از نقاط شروع رشد جدی PostgreSQL بود. جالب‌تر اینکه سال‌ها بعد، وضعیت MySQL واقعاً تغییر کرده. در سپتامبر ۲۰۲۵، Oracle تعدادی از نیروهای تیم اصلی MySQL رو تعدیل کرد و این موضوع دوباره بحث آینده MySQL رو داغ کرد.

در طرف مقابل، PostgreSQL طی این سال‌ها رشد خیلی زیادی داشته. این دیتابیس در سال ۲۰۲۳ به محبوب‌ترین دیتابیس بین توسعه‌دهنده‌ها تبدیل شد و شرکت‌هایی مثل Microsoft، Google و Amazon هم سرویس‌های خودشون رو بر پایه سازگاری با PostgreSQL توسعه دادن.

استون‌بریکر درباره وضعیت امروز MySQL حتی از عبارت خیلی تندی استفاده کرده و گفته این پروژه داره به رقیبی تبدیل می‌شه که عملاً در حال محو شدنه.

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

شاید بزرگ‌ترین مزیت PostgreSQL همین استقلال باشه. وقتی یک پروژه به یک شرکت واحد وابسته نباشه، تصمیم‌های تجاری یک شرکت نمی‌تونن به‌تنهایی مسیر آینده اون رو تعیین کنن.

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

#PostgreSQL
#MySQL
#Oracle
#Database
#OpenSource
#SQL
#SoftwareEngineering
#Developers
#Backend
#Technology
#Programming
#DatabaseManagement

خیلی‌ها از Programming می‌ترسن، ولی اگر بخوام صادق باشم، خود کدنویسی برای من بخش ساده‌ی ماجراست. بخش سخت‌تر، تمام زمانی‌ـه که صرف ساختن Logic توی ذهنت می‌کنی و فکر کردن به تمام حالت‌هایی که ممکنه یک راه‌حل در اون‌ها شکست بخوره.

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

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

شاید برای همینه که همیشه Chess رو هم دوست داشتم. به نظرم Coding و Chess خیلی بیشتر از چیزی که در ظاهر به نظر میاد به هم شبیهن. توی هر دو، باید چند حرکت جلوتر رو ببینی، حالت‌های مختلف رو تصور کنی، اشتباهات احتمالی رو پیش‌بینی کنی و بدون عجله بهترین تصمیم ممکن رو پیدا کنی.

واقعاً نمی‌دونم اگر Programming و Chess وارد زندگی من نمی‌شدن، امروز چه شکلی فکر می‌کردم یا کجا بودم. ولی مطمئنم هر دو، بیشتر از اینکه فقط یک مهارت یا سرگرمی باشن، روی نحوه فکر کردنم تأثیر گذاشتن.

#Programming
#Coding
#Chess
#ProblemSolving
#CriticalThinking
#Logic
#SoftwareEngineering

شاید یکی از دلایلی که امروز صدها Open Source C2 داریم ولی تعداد خیلی کمی از اون‌ها واقعاً در دنیای واقعی قابل استفاده‌ان، همین باشه.

بعد از یه نقطه مشخص، واقعاً Coding بخش کوچکی از نتیجه نهایی می‌شه. شاید حتی همون ۱۰ درصدی که همه بیشتر می‌بیننش. بخش اصلی ماجرا جاییه که باید خارج از چارچوب معمول فکر کنی، Research خودت رو انجام بدی، فرضیاتت رو به چالش بکشی و یک سناریو رو بارها و بارها تست کنی.

ساختن چیزی که روی کاغذ کار می‌کنه یک مسئله‌ست. ساختن چیزی که در دنیای واقعی قابل اتکا باشه، مسئله کاملاً متفاوتیه.

برای همین فکر می‌کنم تفاوت بین یک پروژه معمولی و یک ابزار واقعاً کاربردی، اغلب نه در تعداد Lines of Code، بلکه در میزان فکر، تحقیق و Testing پشت اون مشخص می‌شه.

در نهایت Coding شاید فقط ۱۰ درصد نتیجه باشه. ۹۰ درصد دیگه مربوط به طرز فکر، Research و تست بی‌پایانه.

#Programming
#Cybersecurity
#RedTeam
#C2
#OpenSource
#OffensiveSecurity
#Pentesting
#SoftwareEngineering
#Research
#ProblemSolving

یک موضوع دلی رو بگم بهتون دوستان.

امروز داشتم با یکی از دوستام صحبت می‌کردم و یاد یه عادت قدیمی افتادم. سال ۲۰۱۸، وقتی تازه شروع کرده بودم Windows Internals رو یاد بگیرم، من و چندتا از دوستام یه عادت نسبتاً ساده برای خودمون ساخته بودیم.

هر روز ۱۰ تا فایل EXE یا DLL از System32 انتخاب می‌کردیم و فقط درباره‌شون می‌خوندیم. نه خبری از Hack خاصی بود، نه Reversing و نه کار عجیب‌وغریبی. اسم فایل، کاربردش، اینکه چرا وجود داره، چه کاری انجام می‌ده و هر چیزی که می‌شد درباره‌ش پیدا کرد.

این کار رو تقریباً ۶۰ روز ادامه دادیم و حجم دانشی که فقط با Google کردن و خوندن به دست آوردیم واقعاً عجیب بود.

خیلی وقت‌ها فکر می‌کنیم برای یادگیری یک حوزه حتماً باید یک Course گرون، یک کتاب خاص یا یک مسیر پیچیده داشته باشیم. در حالی که اصل ماجرا خیلی ساده‌تره. یک موضوع مشخص انتخاب کن، هر روز براش وقت بذار و این کار رو با Discipline ادامه بده.

خیلی‌ها با دیدن مباحث Advanced از همون اول می‌ترسن، در حالی که چیزی که واقعاً تفاوت ایجاد می‌کنه، کیفیت Fundamentals هست.

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

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

و البته بله، من خودم چندتا Course هم می‌فروشم؛ ولی حتی با وجود این، هنوز فکر می‌کنم چیزی که بیشتر از هر منبعی نتیجه می‌ده، Time + Consistency + Discipline هست.

#WindowsInternals
#Cybersecurity
#Programming
#Fundamentals
#Learning
#ReverseEngineering
#Infosec
#Security
#SoftwareEngineering
#Discipline

صرفاً Prompt نوشتن و کپی کردن خروجی AI ازت Developer نمی‌سازه.

اگر کدی که AI برات نوشته رو نمی‌فهمی، نمی‌تونی Debug اش کنی، نمی‌دونی چرا این Architecture انتخاب شده و وقتی چیزی خراب می‌شه نمی‌فهمی مشکل از کجاست، در واقع بیشتر از اینکه Developer باشی، AI Babysitter هستی.

وایب کدینگ خودش مشکلی نداره. مشکل از جایی شروع می‌شه که فکر کنی استفاده از AI جای فهمیدن Programming رو گرفته.

#VibeCoding
#Programming
#SoftwareEngineering
#AI
#Developers
#Coding

واقعاً چرا هنوز توی خیلی از مصاحبه‌های Programming ازت می‌خوان Code رو از صفر و با دست بنویسی؟

وقتی قراره در دنیای واقعی از AI برای کدنویسی استفاده کنیم، شاید بهتر باشه مصاحبه‌ها هم از این مدل ارزیابی فاصله بگیرن.

به‌جای اینکه ببینیم کسی چقدر سریع می‌تونه چند خط Code رو بدون کمک بنویسه، بهتر نیست درباره Fundamentals سؤال بپرسیم؟ اینکه چرا یک تکنولوژی رو انتخاب می‌کنی، چطور یک مسئله رو تحلیل می‌کنی، چطور Architecture مناسب رو انتخاب می‌کنی، چطور یک Bug رو پیدا می‌کنی و چطور تشخیص می‌دی کدی که AI تولید کرده واقعاً درست و قابل استفاده هست یا نه.

در نهایت، AI می‌تونه Code رو بنویسه. چیزی که هنوز باید خود Developer بلد باشه، فهمیدن مسئله و تصمیم گرفتن درباره راه‌حل درستشه.

شاید وقتشه Technical Interview هم خودش رو با دنیای AI وفق بده.

#AI
#Programming
#Coding
#SoftwareEngineering
#TechnicalInterview
#Developers
#VibeCoding
#ArtificialIntelligence

یه پدیده جالب با زیاد شدن ابزارهای AI به وجود اومده: آدم‌هایی که چند ماه با مدل‌های زبانی کار کرده‌اند و ناگهان خودشون رو متخصص AI معرفی می‌کنند.

مسئله این نیست که از AI استفاده می‌کنند. اتفاقاً استفاده از AI می‌تونه یک مهندس رو چند برابر سریع‌تر کنه.

مشکل از جایی شروع میشه که خروجی مدل رو بدون اینکه بفهمی، قبول کنی.

مدل کد می‌نویسه، تو اجراش می‌کنی و چون کار کرد، مستقیم می‌ره Production.

مدل یک تحلیل امنیتی تولید می‌کنه، تو همون رو داخل گزارش می‌ذاری.

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

اینجا دیگه AI ابزار نیست؛ تبدیل شده به جایگزین دانش.

و این خطرناک‌ترین قسمت ماجراست.

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

در امنیت سایبری این موضوع حتی جدی‌تره. تصور کنید کسی با کمک AI یک Security Audit انجام بده، اما خودش درک عمیقی از Web Security، شبکه، سیستم‌عامل یا معماری برنامه نداشته باشه. ممکنه گزارش خیلی حرفه‌ای به نظر برسه، اما چند آسیب‌پذیری مهم کاملاً از دست برن.

در نهایت هم وقتی چیزی خراب بشه، کسی باید بیاد و بفهمه واقعاً چه اتفاقی افتاده.

اینجاست که تفاوت «AI User» و «Engineer» مشخص میشه.

مهندس از AI استفاده می‌کنه، ولی خروجی AI رو بررسی می‌کنه.

می‌تونه توضیح بده چرا این کد کار می‌کنه.

می‌تونه تشخیص بده کجا احتمال Hallucination وجود داره.

می‌تونه خروجی مدل رو تست و نقد کنه.

و مهم‌تر از همه، اگر AI اشتباه کرد، خودش متوجه میشه.

من کاملاً موافق استفاده از AI هستم و فکر می‌کنم کسی که امروز از ابزارهای AI استفاده نمی‌کنه، بخشی از بهره‌وری خودش رو از دست میده.

اما یک جمله رو باید همیشه یادمون باشه:

هوش مصنوعی می‌تونه سرعت کار یک مهندس رو بالا ببره؛ ولی نمی‌تونه مسئولیت فهمیدن کار رو از دوش مهندس برداره.

چکش، نجار نیست.

#هوش_مصنوعی
#مهندسی_نرم_افزار
#امنیت_سایبری

#AI
#SoftwareEngineering
#CyberSecurity

مایکروسافت یک قدم جدی دیگه با Rust برداشت.

طبق اعلام یکی از مهندسان ارشد بخش ابزارهای توسعه مایکروسافت، Rust حالا به یکی از زبان‌های اصلی توسعه داخلی این شرکت تبدیل شده و در کنار C++، C# و TypeScript قرار گرفته.

نکته جالب‌تر اینه که این فقط یک تصمیم روی کاغذ نیست. مایکروسافت همین حالا از Rust در بخش‌هایی از Windows، Office و حتی Copilot استفاده می‌کنه.
به نظرم مهم‌ترین بخش خبر همین‌جاست.

سال‌ها C و C++ انتخاب اصلی برای بخش‌هایی بودن که performance و کنترل پایین‌سطح اهمیت داشت. ولی مشکل memory safety همیشه یکی از چالش‌های بزرگ این حوزه بوده.

راست دقیقاً اینجا وارد می‌شه؛ سعی می‌کنه performance نزدیک به زبان‌های سیستم‌سطح رو نگه داره، ولی بخش بزرگی از خطاهای مربوط به memory safety رو در زمان کامپایل کنترل کنه.

اینکه مایکروسافت Rust رو در کنار C++ و C# و TypeScript به‌عنوان یکی از زبان‌های اصلی داخلی خودش قرار داده، به نظرم نشون می‌ده جایگاه Rust داره از «زبان جذاب برای پروژه‌های جدید» به «ابزار جدی برای زیرساخت و محصولات بزرگ» تغییر می‌کنه.

البته این به معنی کنار گذاشتن C++ نیست. برای چنین شرکتی احتمالاً سال‌ها باید هر دو زبان کنار هم وجود داشته باشن.

ولی برای کسی که می‌خواد وارد حوزه‌هایی مثل سیستم‌پروگرمینگ، امنیت، زیرساخت یا نرم‌افزارهای performance-critical بشه، به نظرم Rust دیگه زبانی نیست که بشه خیلی راحت نادیده‌اش گرفت.

راست کم‌کم داره جای خودش رو پیدا می‌کنه. 🦀

#برنامه_نویسی
#راست
#مایکروسافت
#Rust
#Microsoft
#SoftwareEngineering

به نظرم خیلی‌ها دارن بدون اینکه واقعاً بفهمن کدی که تولید می‌کنن چطور کار می‌کنه، همین‌طوری YOLO می‌کنن.

با Vibe Coding بعضی وقت‌ها واقعاً می‌تونی از A برسی به Z.

ولی خیلی وقت‌ها چیزی که تحویل می‌گیری اینه:

A → F + N → Z

وسطش خالیه.

مدل بهت می‌گه:
«انجام شد، از A تا Z کامل شد.»

و تو هم بررسی نمی‌کنی.

یا حتی بدتر؛ از خود مدل می‌خوای که کد خودش رو بررسی کنه.

اینجاست که یه مشکل جدی به وجود میاد.

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

برای همین من فکر می‌کنم Vibe Coding قرار نیست جای فهمیدن رو بگیره.

هوش مصنوعی رو استفاده کن.

سریع‌تر کد بزن.

کارهای تکراری رو بده بهش.

ولی از Loop خارج نشو.

کدی که نمی‌فهمی چطور کار می‌کنه، واقعاً هنوز مال تو نیست.



#VibeCoding
#AI
#Programming
#SoftwareEngineering
#Developers
#LLM

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

و Pexo سعی کرده کل این فرایند رو یک‌جا انجام بده. شما Brief رو می‌دید و خودش ویدیوی نهایی رو با Voiceover، موسیقی و Caption آماده می‌کنه.
حتی تغییرات بعدی رو هم میشه با Chat انجام داد، بدون اینکه وارد Timeline بشید.

به نظرم برای تولید سریع محتوای Social Media می‌تونه جالب باشه. اگر اهل ساخت ویدیو هستید، توصیه می‌کنم یه تستی باهاش بگیرید.


http://invite.pexo.ai/4AioGJm


#LLM
#AI
#SoftwareEngineering
#Technology

بعضی‌ها معتقدن تا سال ۲۰۳۶، هوش مصنوعی می‌تونه بخش بزرگی از بیماری‌هایی که امروز درمان قطعی براشون نداریم، مثل سرطان و آلزایمر، رو قابل‌درمان یا قابل‌کنترل کنه.

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

البته اینکه بگیم «تا ۲۰۳۶ همه بیماری‌ها درمان میشن» فعلاً بیشتر یک پیش‌بینی خوش‌بینانه‌ست تا یک واقعیت علمی قطعی. ولی سرعت پیشرفت این حوزه واقعاً قابل توجهه.

البته من با این گزاره تا سال 2036 مخالفم!!!!

#Ai
#SoftwareEngineering
#LLM
#Technology
#AIAgents
#Cancer

طبق سایت DB-Engines، صدها سیستم مدیریت پایگاه داده در دنیا وجود دارن که هرکدوم برای نیازها و سناریوهای متفاوتی طراحی شدن.



رتبه‌بندی اینه:

۱. Oracle
۲. MySQL
۳. Microsoft SQL Server
۴. PostgreSQL
۵. MongoDB
۶. Snowflake
۷. Databricks
۸. Redis
۹. IBM Db2
۱۰. Apache Cassandra

نکته جالب اینجاست که همه این سیستم‌ها دقیقاً یک کار رو به یک روش انجام نمی‌دن.

مثلاً MySQL و PostgreSQL بیشتر برای ذخیره و مدیریت داده‌های رابطه‌ای شناخته می‌شن؛ Redis روی ذخیره‌سازی داده‌های کلید-مقدار و دسترسی سریع تمرکز داره.

و خود Snowflake و Databricks هم بیشتر در دنیای تحلیل داده و پردازش‌های سنگین مطرح هستن.

و SQLite هم با وجود سبک بودن و نداشتن نیاز به سرور جداگانه، یکی از گزینه‌های مهم برای اپلیکیشن‌ها و پروژه‌های سبک محسوب می‌شه.

البته یه نکته مهم: رتبه DB-Engines لزوماً به معنی بیشترین نصب یا استفاده واقعی نیست. این رتبه‌بندی از شاخص‌هایی مثل میزان توجه در وب، بحث‌های فنی، آگهی‌های شغلی و حضور در فضای حرفه‌ای استفاده می‌کنه.

در نهایت، بهترین دیتابیس لزوماً رتبه اول رو نداره.
انتخاب درست به نوع پروژه، حجم داده، الگوی دسترسی، مقیاس‌پذیری و نیازهای فنی بستگی داره.



#برنامه_نویسی
#پایگاه_داده
#فناوری

#Database
#DBEngines
#SoftwareEngineering