tech-afternoon

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

در نهایت به عنوان یک دیجی کالایی،امروز دیجی کالا مهر برای من مسیر رسیدن به: امید یک معلم، مسیر نجات یک فرزند و احقاق حق اولیه یه انسانه.

ازتون میخوام در صورتی که امکانش رو دارید در پویش "هر جا که تویی" شرکت کنید و برای آینده کودکان کشورمون سهمی داشته باشید :

https://mehr.digikala.com/madrese-besaz/

@learning_with_m

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

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

اگر به اعداد بخوایم نگاه کنیم هم: مطالعات مشهور جیمز هکمن و همکارانش درباره برنامه‌های باکیفیت در کودکی برای خانواده‌های محروم، بازدهی سرمایه‌گذاری اقتصادی بلندمدت حدود ۱۳.۷ درصد در سال رو برآورد کردن؛ منفعتی که فقط توی درآمد آینده خلاصه نمی‌شه و سلامت، آموزش و حتی کاهش جرم رو هم شامل می‌شه.

تخمین بانک جهانی هم به‌طور متوسط هر یک سال آموزش بیشتر، حدود ۱۰ درصد درآمد بیشتر در آینده رو میگه. یعنی کمک به آموزش یه کودک، اگر درست و مؤثر انجام بشه، صرفاً کمک به امروزش نیست؛ داریم روی چند دهه بعد یه جامعه سرمایه‌گذاری می‌کنیم.

پی‌نوشت ۱: دلیل کم‌کاری و مطلب نداشتن، مشغله کاری است، ولی سعی می‌کنم تا زودتر مطلب مربوط به Jev (از نگاه چرایی، معماری و تعاریف پایه‌ایش) رو جمع کنم. تا بعدش ببینیم کی فرصت می‌شه تا «آیا بیکار خواهیم شد» رو بنویسم. 😊

پی‌نوشت ۲: اگر در حوزه AI کار می‌کنید حواستون به اتفاقات مهم و ریلیز‌های پیشِ رو در حوزه sandbox، memory، orchestration، subagents، باشه! غیب‌گویی نیست، ترند مقالاتی که دانشگاه‌های پیشرو یا هسته‌های تحقیقاتی گوگل و اوپن ای‌آی و... منتشر می‌کنن نشون میده بهینه‌سازی‌های بزرگی در راهه. اگر کسی علاقه‌مند پیام بده.

پی‌نوشت ۳: اگر توی لایه اپلیکیشن فعالید؛ حواستون به ریلیزهای هفته‌های پیشِ رو، مثل پستگرس ۱۹، دات‌نت ۱۱، Python 3.15 باشه؛ نه در حد آپدیت کردن، بلکه تغییرات مهم زیر پوسته‌ی اصلی...

☑ چک‌لیست آماده‌سازی تیم، فرایندها و زیرساخت برای توسعه با AI

توجه: هیچ چک‌لیستی جهان‌شمول نیست؛ ولی می‌تونه بهانه و سرنخ‌هایی برای فکر کردن باشه.

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


🔗 لینک به مطلب کامل

گوفر رو رنجوندید! شرم بر شما 😂

سومین بار بود این موضوع تحلیل عمیق GC جدید گو رو توی نظرسنجی‌ها گذاشتم؛ و زیباجویان عزیز نادیده گرفتید.

پکیج موفقیت و راز شادابی پوست ۱۸ رأی؛ مطلب به اون عمیق ۴ رأی!؟

از زبون آمار: آیا AI کدهای خوبی می‌نویسه یا نه؟

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

گزارش GitClear با بررسی بیش از ۶۲۳ میلیون تغییر کد نشون می‌ده هم‌زمان با رشد شدید استفاده از AI، الگوی تغییرات کد هم عوض شده: Refactoring نسبت به ۲۰۲۳ حدود ۷۰٪ کاهش پیدا کرده، در حالی که Copy/Paste حدود ۴۱٪ و Code Duplication حدود ۸۱٪ بیشتر شده!

نکته‌ی جالب‌ترش اینه که نویسنده‌های مطلب نمی‌گن «AI کد بد می‌نویسه». مسئله اینه که Agent معمولاً همون چیزی رو که ازش خواستن تحویل می‌ده: یعنی Feature کار می‌کنه، Unit Test پاس می‌شه، Ticket بسته می‌شه. اما انسان موقع انجام همون درخواست، «ممکنه» اطراف مسئله رو هم ببینه، یک abstraction قدیمی رو اصلاح کنه، duplication رو حذف کنه یا بخشی از معماری رو تمیزتر کنه. این «کارهای جانبی» معمولاً داخل Prompt یا Acceptance Criteria نیستن و در نتیجه به‌سادگی حذف می‌شن.

شاید مهم‌ترین جمله‌ی گزارش همین باشه: ارزش یک Senior Developer خیلی وقت‌ها توی کدی نیست که اضافه می‌کنه، بلکه توی کدیه که لازم نیست اضافه بشه یا لازمه حتی حذف بشه.

داده‌های گزارش نشونه‌های نگران‌کننده‌ای دارن: ارتباط کدهای جدید با بخش‌های موجود سیستم ۳۵٪ کاهش یافته و نگهداری کدهای قدیمی بیش از ۷۰٪ افت کرده. یعنی ممکنه با AI سریع‌تر از همیشه Feature بسازیم، ولی اگر آگاهانه برای reuse، refactoring و معماری وقت نگذاریم، چیزی که تحویل می‌گیریم مجموعه‌ای از v1های مستقله که هر روز بزرگ‌تر می‌شن.

و شاید خلاصه‌ی کل گزارش همین باشه: بزرگ‌ترین ریسک AI این نیست که کدی تولید کنه که نتونیم نگه‌داریش کنیم؛ اینه که صورت‌حساب بدهی فنی‌ای که اصلاً اندازه‌گیریش نکردیم، دقیقاً توی بدترین زمان سر برسه 🧨😅

این به معنی نهی از AI نیست؛ بلکه امر به درست استفاده کردنشه 😅

❤️ فایل گزارش کامل رو اگر دوست داشتید بخونید...

۱۳ سپتامبر، روز برنامه‌نویس... چی شد که برنامه‌نویس شدم!

برای هر کسی که به نحوی ذیل این عنوان شغلی جا می‌گیره؛ یه مشوق یا دلیل یا محرک اولیه وجود داشته که مرورش بعد از چند سال می‌تونه جالب باشه.
برای یکی رتبه کنکور بوده، برای یکی علاقه‌ای که یه معلم توی مدرسه براش ایجاد کرده، یکی دیگه شاید توسط یکی از اقوام و آشنایانش و...

برای من، چهارم ابتدایی رفتم (ثبت‌نامم کردن) کلاس برنامه‌نویسی، ولی حتی یک کلمه هم یاد نگرفتم! 😅 به معنی واقعی کلمه «هِچ!»
تا اینکه اول راهنمایی، توی سیلابس رسمی مدرسه، برنامه‌نویسی داشتیم، درس رسمی بود و فوق‌برنامه یا دل‌بخواه نبود، عین دروس رسمی هم سخت می‌گرفتن. خوبیش این بود که اصولی از اینکه کامپیوتر و نرم‌افزار قراره چی «مسئله‌ای» رو حل کنه شروع شد؛ بعدترش الگوریتم و فلوچارت، از شکستن مراحل کلی به جزئی و... بعد هم زبان لوگو روی کومودور؛ بعدش زبان قلم‌طراح، بعدش GW-Basic و... ولی کماکان یه درسی بود مثل ریاضی و علوم، با اینکه نمراتم خوب بود، ولی علاقه خاص و متفاوتی از بقیه درس‌ها نداشتم.

تا سوم راهنمایی: اون وقت‌ها سال تحصیلی ۳ تا ثُلث بود؛ برای پروژه درس برنامه‌نویسی ثُلث دوم به من «معادله درجه دوم در صورت دلتای منفی» رو دادن! اون وقت‌ها معادله درجه دوم رو اول دبیرستان درس می‌دادن، دلتای منفی رو هم می‌گفتن جواب نداره و برید سال اول دانشگاه یاد بگیرید. برای من چالش بزرگ، فهمیدن ذات معادله درجه دوم بود بعدش دلتای منفی و... باید وقت ناهار از ناظم نامه می‌گرفتم می‌رفتم کتابخونه‌ی دبیرستان بگردم ببینم اصلا چی به چیه!

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

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

تنبلی نکنید و کامنت کنید چی باعث شد بیاید سمت نرم‌افزار 😊 ولو اینکه بگید جبر زمانه، شانس، رفیق بد و زغال مرغوب؛ حتماً جالبه!

اگر هم علاقه‌مند بودید در مورد اینکه «سرمایه‌گذاری قبل از دبستان از دانشگاه اثرگذارتره» بیشتر بدونید پیشنهاد می‌کنم تحقیقات Perry، Abecedarian و Heckman رو بخونید

لیدرشیپ فنی؛ یک انتخاب در مسیر رشد، یا گذرگاهی اجباری؟

مهندس خوبی بوده، پس مدیرش کنیم!
حقوق بیشتری می‌خواد؟ یه تیم هم بهش بدیم!
گاهی همین تصمیمِ ظاهراً خیرخواهانه، هم یک مهندس توانمند رو از کار موردعلاقه‌اش دور می‌کنه، هم یک تیم رو گرفتار.
توی این مطلب، اینکه قبل از پذیرفتن یا سپردن مسئولیت، چه چیزهایی رو باید بررسی کنیم رو نوشتم.

🔗 لینک مطلب

💬 خوشحال می‌شم نظر و نقدتون رو بخونم.

🤖 بررسی Agent-First Development؛ چه کاری رو واگذار می‌کنیم، و از کجا می‌فهمیم می‌ارزه؟

ایجنت تست رو سبز کرده؛ ولی با ضعیف‌کردن خودِ تست! این مثال ساده، شروع مطلبی درباره Agent-First Development است. اینکه چجوری کار رو به Agent واگذار کنیم، درستیِ خروجیش رو بسنجیم و بفهمیم مجموع هزینهٔ اجرا و بازبینی واقعاً می‌ارزه؟

دربارهٔ شواهد بهره‌وری، مرز اختیار و تصمیم به ادامه‌دادن یا متوقف‌کردن هم نوشته‌ام. چون قرار نیست هر آزمایشی به استفادهٔ بیشتر از AI ختم بشه.

لینک مطالعه مطلب:
🔗 بررسی Agent-First Development

💬 نظر و تجربه‌تون رو اگر بنویسید خوشحال می‌شم. در ضمن موضوع بعدی، بر اساس آراء نظرسنجی در مورد پیش‌نیازهای لیدرشیپ خواهد بود؛ تا زمان نوشتنش اگر نکته یا سوالی دارید حتمن طرح کنید تا گپ بزنیم در موردش

🎞 داستان VS Code | فیلم مستند

فیلم مستندی که چند ساعت پیش منتشر شد، و چه با VS Code کار می‌کنید، و چه از ادیتور دیگه‌ای استفاده می‌کنید، دیدنش رو پیشنهاد می‌کنم. داستان محصولیه که از Monaco و ادیتور داخل مرورگر شروع شد، به Electron و دسکتاپ رسید و بعدش با Open Source، شدنش و Extensionها و LSP عملاً تبدیل به یک پلتفرم شد.

بخش جذابش فقط تاریخچه نیست؛ درباره تصمیم‌های مهندسی پشت Performance و Extensibility، فلسفه‌ی Meet Developers Where They Are، و شکل‌گیری اکوسیستم VS Code و در نهایت تغییر دوباره‌‌اش در دوره AI، با Copilot و Forkهایی مثل Cursor صحبت می‌کنه.

همون «موفقیت یک‌شبه‌ای» که به قول Erich Gamma، ده سال طول کشید! 😅

🎞 لینک یوتیوب

⚡️ 🚩 داستان Feature Flag؛ از یک if ساده تا چیزی که کسی جرئت حذفش رو نداره!

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

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

بله، این‌ها همون‌هایی هستن که یا هنوز نمی‌دونن Feature Flag چیه، یا پیاده‌سازی درستش رو بلد نیستن و در شرایط بحرانی آرزو می‌کنن کاش توی صف قضای حاجت بودن، ولی درگیر اون پروژه نبودن!

البته از این گروه بدبخت‌تر هم داریم: کسانی که یه کدبیس با ده‌ها یا صدها Feature Flag رهاشده بهشون ارث رسیده و حالا هیچ‌کس جرئت نمی‌کنه چیزی رو حذف کنه!

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

- انواع Feature Flag و تفاوت Flagهای موقت و دائمی

- بدهی فنی، ترکیب‌های غیرقابل‌تست و Flagهایی که هیچ‌وقت حذف نمی‌شن

- پلتفرم‌هایی مثل LaunchDarkly، Unleash، Flagsmith و OpenFeature

- اصول Governance، نام‌گذاری، مالکیت و معیارهای سنجش بدهی

- در مورد Consistency، Performance و امنیت Feature Flag در سیستم‌های توزیع‌شده

می‌شه گفت Feature Flag بدهی فنی نیست؛ اما Feature Flag بدون مالک، تاریخ انقضا و برنامه حذف، بدهی فنی زمان‌بندی‌شده است.

🔗 لینک کامل مطلب

اگر شما هم Feature Flagی دیدید که هیچ‌کس نمی‌دونه چرا هنوز وجود داره، تجربه‌تون رو بنویسید؛ احتمالاً تنها نیستید!

حکایت چینی «کشیدن نهال برای اینکه زودتر رشد کنه» (拔苗助长)

۲۴۰۰ سال پیش، منسیوس فیلسوف چینی و از شاگردان مکتب کنفسیوس؛ از کشاورزی حکایت می‌کنه که از رشد آهسته نهال‌هایش کلافه شده بوده؛ و برای کمک به رشد سریع‌ترشون، شروع می‌کنه نهال‌ها رو از ساقه کمی به بالا می‌کشه. فردا می‌بینه همه نهال‌ها پژمرده شدن.

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

💡مراقب باشیم آدم‌ها رو با ارتقاء نابه‌هنگام خراب نکنیم؛ و مراقب باشیم آدم‌های دیگه بر اساس شناخت کم؛ تصورات غیردقیق؛ یا حتی برای تسریع رسیدن به هدف‌های خودشون؛ با ارتقاء زودهنگام ما، جلو رشدمون رو نگیرن! (سیب کال رو از درخت نچینیم؛ چون نه قابل استفاده خواهد بود، و نه فرصت رسیدن رو خواهد داشت).

اگر دوست داشتید بیشتر بخونید:
- Peter Principle
- Law of the Farm
- HiPo Derailment
- Zone of proximal development (منطقه مجاور رشد, این موضوع مهمیه)
- Shu Ha Ri

🖊 وایب‌گاورنینگ چیست؟

کوتاه: یک عبارت من‌درآوردی که خودم ساختم!

متوسط: همون وایب‌کدینگ، ولی در حوزه‌ی سیاست‌گذاری و حکمرانی.

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

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

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

توی وایب‌کدینگ اگه نفهمی چی ساختی، نهایتاً ممکنه یه نرم‌افزار رو خراب کنی.
توی وایب‌گاورنینگ، production خود جامعه ست، userها حق opt-out ندارن و rollback هم پرهزینه، دشوار یا حتی غیرممکنه.

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

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

پی‌نوشت ۲: توی وایب‌کدینگ؛ مدل هوش مصنوعی «نه» نمی‌گه. گند می‌زنه، اشتباه می‌کنه، ولی ذاتا با وایب‌کدر درگیر نمی‌شه و اصطکاکی نداره؛ توی جامعه اما باید اصطکاک (از نوع سازنده) وجود داشته باشه: نقد صحیح و سازنده، نهاد، تخصص، سازمان، رسانه، داده و خصوصا حس مسئولیت و دلسوزی نسبت به نتیجه‌ی تصمیم.
اینا به‌نوعی compiler و type checker حکمرانی‌ان.

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

باگ ۱۶ ساله‌ی SQLite، و شش ماه زمان که Tailscale صرف پیدا کردنش کرد!

این ماجرای جالبیه از مشکل SQlite که سال‌ها وجود داشته ولی بین این همه کاربر SQLite که از پروژه کوچیک شخصی تا زیرساخت‌های بزرگ ازش استفاده کردن؛ گریبان‌گیری Tailscale شد. داستان مهندسی پشتش و پیدا کردن دلیلش اینقدر جالب بود که به صورت کامل‌تر (با توضیحات اضافه که برای دوستانی که جزئیات دیتابیس‌ها رو نمی‌دونن هم بار آموزشی داشته باشه و مبهم نمونه) 🔗 اینجا نوشتم.

من در مورد دیتابیس حداقل ۲ مورد مشابه رو تجربه کردم که باگ جدی گریبان‌گیر یه شرایط خیلی خاص شد؛ یکیش حتی به مکاتبه با Kimberly کشید و اونم گفت نمیشه کاری کرد؛ ولی چند ماه تعطیل کردن اکثر کارها برای تمرکز روی یک باگ و بارها سفر به جنوب منجر به حلش شد. و دومی ۳۶ ساعت کار بدون وقفه (در حد غذا و...) و جمع کردن حجم عظیمی از لاگ‌ها نتونست کمک کنه تا اینکه از جایی که عقل جن هم بهش نمیرسید ایراد رو پیدا کردم. متاسفانه در شرایط فعلی ترجیح می‌دم توضیح بیشتری ندم درحالیکه دوست دارم روزی با جزئیات، داستان و مسیر حلشون رو بنویسم.

این دو تا باگ؛ جزو تجربیاتی بود که به «یادگیری عمیق» من از انجین دیتابیس و لایه‌های پایین‌تر خیلی کمک کردن؛ این که دقیقا خود انجین چجوری برخی کارها رو انجام میده (خوندن این دو تا فایل از pg 8.1 و ده‌ها فایل دیگه ازش کمک کرد یه بخشی از انجین دیگه‌ای که کدش بسته بود رو با حدس بفهمم و برای منظور خاص بخشی از رفتار انجین رو طوری بازنویسی کنم که رفتار مورد نظرم رو انجام بده تا مسئله رو بشه حل کرد فایل ۱ و فایل ۲)