tech-afternoon
Відкрити в Telegram
مطالب تِک‌افترنون حول AI، معماری و توسعه نرم‌افزار؛ و موضوعات مرتبط با تکنیکال لیدرشیپ است. https://mesbahi.net/fa/ youtube.com/@AminTechTalks/videos امین مصباحی
Показати більше1 699
Підписники
Немає даних24 години
+17 днів
+3930 днів
Триває завантаження даних...
Схожі канали
Немає даних
Виникли проблеми? Будь ласка, оновіть сторінку або зверніться до нашого support-менеджера.
Хмара тегів
Вхідні та вихідні згадування
---
---
---
---
---
---
Залучення підписників
жовтень '26жовт '26
жовтень '26
+14
в 0 каналах
вересень '26
+72
в 3 каналах
Get PRO
серпень '26
+97
в 5 каналах
Get PRO
липень '26
+122
в 4 каналах
Get PRO
червень '26
+100
в 3 каналах
Get PRO
травень '26
+84
в 1 каналах
Get PRO
квітень '26
+18
в 0 каналах
Get PRO
березень '26
+5
в 0 каналах
Get PRO
лютий '26
+53
в 4 каналах
Get PRO
січень '26
+41
в 4 каналах
Get PRO
грудень '25
+86
в 4 каналах
Get PRO
листопад '25
+1 142
в 4 каналах
| Дата | Залучення підписників | Згадування | Канали | |
| 12 жовтня | +2 | |||
| 11 жовтня | +2 | |||
| 10 жовтня | 0 | |||
| 09 жовтня | +1 | |||
| 08 жовтня | 0 | |||
| 07 жовтня | +1 | |||
| 06 жовтня | +1 | |||
| 05 жовтня | +1 | |||
| 04 жовтня | +2 | |||
| 03 жовтня | +1 | |||
| 02 жовтня | +2 | |||
| 01 жовтня | +1 |
Дописи каналу
🧠 وقتی AI یاد می‌گیره روش کار کردن خودش رو بهتر کنه!
مقاله‌ی اخیر Harness Learning Enables Generalizable Test-Time Adaptation (از دانشگاه کارنگی ملون که جزو بهترین دانشگاه‌های آمریکا توی علوم کامپیوتره) ایده‌ی بهبود عملکرد یه مدل، از طریق سیستمی که مدل داخلش کار می‌کنه، به جای تغییر وزن‌ها و آموزش مجددش رو مطرح می‌کنه.
به مجموعه‌ی دستورالعمل‌ها، ابزارها، گردش کار و نحوه‌ی مدیریت اطلاعات که رفتار یک Agent رو شکل میده؛ harness می‌گن.
نویسنده‌ها مدلی رو آموزش دادن که با مشاهده‌ی نتیجه‌ی اجرای Agent، برنامه‌ی اجرایی اون رو اصلاح می‌کنه. جالب‌تر اینکه این تواناییِ اصلاح و سازگاری، تا حدی به مسئله‌های جدیدی که در زمان آموزش ندیده هم تعمیم پیدا کرده، بدون اینکه وزن‌های مدل اصلی تغییر کنن.
شاید بخشی از آینده‌ی Agentها، نه فقط توی مدل‌های بزرگ‌تر، بلکه توی سیستم‌هایی باشه که از تجربه‌های قبلی یاد می‌گیرن چجوری از همون مدل‌ها بهتر استفاده کنن.
این پژوهش هنوز به معنی خودبهبودی نامحدود Agentها نیست، اما مسیر تحقیقاتی خوبی رو نشون میده که برخی شرکت‌ها هم مدت‌هاست روش کار می‌کنن.
📄 مطالعه‌ی مقاله در arXiv
| 2 | 🏎 فرمول یکی که هنوز پیستش نساختن!
راننده‌های فرمول یک قبل از مسابقه، پیچ‌وخم‌های پیست رو بارها مرور می‌کنن. می‌دونند کجا باید ترمز کنن، کجا گاز بدن و کدوم پیچ‌ها خطرناک‌ترن.
حالا تصور کنین مسابقه‌ای برگزار شده که راننده‌ها با سرعت تمام در حال حرکت‌اند، اما برگزارکننده‌ها هنوز دارن چند کیلومتر جلوتر پیست رو می‌سازن! جالب‌تر اینکه خود طراحان پیست هم فقط یک طرح کلی از مسیر آینده دارن و هنوز دقیقاً نمی‌دونن پیچ بعدی قراره به کجا برسه.
به نظرم وضعیت امروز ما توی tech، خصوصاً با ظهور AI، خیلی با این مثال فرق نداره. ماشین‌هامون هر سال سریع‌تر می‌شن، اما میدان دیدمون لزوماً بیشتر نشده. فقط فاصله‌ی بین چیزهایی که امروز می‌دونیم و اونچه که هنوز نمی‌دونیم رو سریع‌تر طی می‌کنیم.
مثلاً امروز، در اکتبر ۲۰۲۶، واقعاً چقدر می‌تونیم درباره‌ی توانمندی‌های AI در ژانویه‌ی ۲۰۲۷ با اطمینان صحبت کنیم؟
در موج‌های قبلی فناوری، مثلاً فراگیر شدن معماری‌های توزیع‌شده، معمولاً فرصت بیشتری برای یادگیری، تجربه کردن و تطبیق مهارت‌هامون داشتیم. البته اون دوران هم برای همه آروم و قابل پیش‌بینی نبود. اما حالا چرخه‌ی تغییر برخی ابزارها و مهارت‌ها به‌قدری کوتاه شده که ممکنه هنوز چیزی رو درست یاد نگرفته باشیم و نسخه‌ی جدیدش از راه برسه.
مسئله دیگه فقط سرعت حرکت نیست؛ سرعت یادگیری، فراموش کردن دانسته‌های منسوخ و سازگار شدن با مسیر جدیده.
اما این مسابقه، یه ویژگی جالب دیگه هم داره: بعضی از مهارت‌هایی که دیروز برای رانندگی ضروری بودن، امروز دیگه مزیت رقابتی محسوب نمیشن که هیچ؛ کسی هم براشون تره خرد نمی‌کنه.
یادتون هست یه روزگاری برای خرید یه کامپیوتر ساده‌ی خونگی باید دست‌به‌دامن «آقای مهندس» می‌شدیم؟ چند سال بعدش، دیگه نیازی به «آقای مهندس» نبود. کافی بود به کامبیز، خدمات کامپیوتری محله، سفارش می‌دادیم؛ تلفنی چهار تا قطعه از بازار می‌گرفت، سرهم می‌کرد و تحویل می‌داد.
بعدتر همین کارها رو جمال، پسرِ خاله‌‌اعظم، انجام می‌داد که از تأمین VPN فامیل تا تنظیم تلویزیون مادربزرگ، همه‌چیز روی سبیلش بود!
و امروز؟ شما با یه دست لقمه‌ی کوکو رو می‌دی سمت خندق بلا، و با اون‌یکی دستت، لپ‌تاپ موردنظرت رو آنلاین سفارش می‌دی.
سؤال: آیا صنعت سخت‌افزار از بین رفت؟ اتفاقاً نه. سخت‌افزار پیچیده‌تر، قدرتمندتر و توی خیلی از بخش‌ها تخصصی‌تر شد. چیزی که تغییر کرد، دسترسی به محصول و ارزش اقتصادی بعضی لایه‌های خدمات واسطه‌ای بود.
چیزی که روزی دانش تخصصی و کمیاب به حساب میومد، به‌تدریج، تبدیل به یه کار ساده و روتین، خودکار یا در دسترس عموم شد.
البته تمام خدمات کامپیوتری‌ها تعطیل نشدن؛ و تمام تکنسین‌های مونتاژ هم بیکار نشدن. بعضی‌شون متخصص شدن، بعضی‌شون هم حوزه‌ی فعالیتشون رو تغییر دادن و بعضی‌شون هم احتمالاً الان دارن کنار دفتر مشق و مداد رنگی، خدمات پرینت و کپی ارائه می‌دن.
حالا همین فرایند رو توی صنعت نرم‌افزار تصور کنید.
این روزها شبکه‌های اجتماعی پر شده از دوستانی که با چند تا Agent، یه‌شبه محصول (بخونید پروتوتایپ) ساختن. بعضی از این تجربه‌ها واقعاً ارزشمندن. اتفاقاً پایین اومدن هزینه‌ی آزمودن ایده‌ها یکی از جذاب‌ترین دستاوردهای AI است. ولی بعضی‌هاشون هم وزن شوآفش بیشتر از هر چیز دیگه‌ایه. اما ساختن چیزی که روی لپ‌تاپ خودمون کار می‌کنه یا نهایتاً روی VPS اجاره‌ای‌مون، الزاماً به معنی ساختن یه محصول نرم‌افزاری نیست. آیا کاربر واقعی داره؟ مسئله‌ای رو حل می‌کنه؟ و اگه قراره تجاری باشه، کسی حاضره بابتش هزینه کنه؟ هزینه‌ی زیرساخت و توکن‌هاش قابل توجیه و بازگشته؟ امنیت و پایداری داره؟ شیش ماه دیگه می‌شه توسعه‌اش داد؟ وقتی توی محیط پروداکشن مشکلی پیش بیاد، کسی می‌تونه ریشه‌ی مشکل رو پیدا کنه؟
اینجاست که فاصله‌ی یک دمو جذاب با یه محصول مهندسی‌شده خودش رو نشون میده.
البته خیلی از محصولات موفق هم از روز اول محصول کامل نبودن. خیلی‌هاشون از یه آزمایش کوچیک شروع شدن. اشکالی هم نداره کسی صرفاً برای یادگیری یا سرگرمی چیزی بسازه.
ایراد از جایی شروع می‌شه که توانایی ابزار رو با دانش و توانایی خودمون اشتباه بگیریم.
ما انسان‌ها قرن‌هاست سعی کردیم سر از چجوری کار کردن هر چیزی در بیاریم؛ حتی سازوکار بدن خودمون رو که محصول طراحی مهندسی خودمون نیست، هنوز به‌طور کامل نمی‌شناسیم. قرن‌هاست داریم روی بدنمون مطالعه می‌کنیم و همچنان چیزهای تازه کشف می‌کنیم.
حالا جالبه که به نقطه‌ای رسیدیم که سیستم‌هایی رو خودمون طراحی و آموزش می‌دیم، اما نمی‌تونیم تمام رفتارهای آموخته‌شده‌ی اون‌ها رو دقیقاً توضیح بدیم. می‌دونیم شبکه‌های عصبی چجوری ساخته و آموزش داده می‌شن، ولی اینکه دقیقاً چه الگوها و بازنمایی‌هایی یاد گرفتن و چرا در شرایط مشخص خروجی خاصی تولید می‌کنن، هنوز از موضوعات جدی پژوهشیه.
پس اگه با ابزاری که خودتون سازوکارش رو درست نمی‌شناسید، خروجی خیره‌کننده‌ای تولید کردید، خوشحال باشید، تجربه کنید، یاد بگیرید و حتی گاهی، و به اندازه، بهش افتخار کنید. اما تمام توانایی‌های ابزار رو به حساب دانایی خودتون نگذارید.
اخوی! اینکه سوار آسانسور بشی و به طبقه‌ی پنجاهم برسی، معناش این نیست که پنجاه طبقه پله‌نوردی بلدی! البته بلد بودن کار با آسانسور هم بد نیست، خصوصاً وقتی دیگران هنوز دنبال پله می‌گردن!
این حرف به معنی بی‌ارزش بودن مهارت استفاده از ابزار نیست. اتفاقاً استفاده‌ی ماهرانه از ابزار خودش تخصصه. اما باید فرق بین استفاده از فناوری، ساختن محصول با فناوری و توسعه‌ی خود فناوری رو بدونیم.
همه هم قرار نیست طراح موتور فرمول یک باشن. راننده‌ی خوب، مهندس مسابقه و طراح موتور هرکدوم مهارت و ارزش خاص خودشون رو دارن. مسئله اینه که بدونیم توی کدوم نقش هستیم و چه ارزشی خلق می‌کنیم.
به گمان من AI قرار نیست لزوماً تمام مهندس‌های نرم‌افزار رو حذف کنه، همون‌طور که ساده‌تر شدن خرید کامپیوتر، صنعت سخت‌افزار رو نابود نکرد. اما می‌تونه بخشی از مهارت‌ها، خدمات و مدل‌های کسب‌وکار فعلی رو کم‌ارزش یا حتی غیرضروری کنه.
از اون طرف، پیچیدگی‌های تازه‌ای هم ایجاد می‌کنه که به دانش و تخصص تازه نیاز دارن (مثل امنیت، یا compliance)
شاید سؤال مهم امروز این نباشه که AI می‌تونه کد بنویسه یا نه. این سؤال رو تا حد زیادی پشت سر گذاشتیم. بلکه سؤال مهم‌تر اینه که وقتی تولید کد ارزون‌تر و آسون‌تر می‌شه، ارزش واقعی مهندس نرم‌افزار کجا خواهد بود؟
در شناخت مسئله؟ طراحی سیستم؟ تصمیم‌گیری بین چند راه‌حل؟ مدیریت پیچیدگی؟ امنیت، پایداری و مسئولیت نتیجه؟ یا توی حوزه‌هایی که هنوز حتی نمی‌دونیم به وجود خواهند آمد؟
شاید ترکیبی از همه‌ی این‌ها، شاید هم چیزی که امروز به اندازه‌ی کافی بهش توجه نمی‌کنیم.
برای همین بد نیست بین این‌همه هیاهوی «AI فلان کار رو کرد» و «Agent بهمان شغل رو حذف کرد»، گاهی از خودمون بپرسیم:
دانش و مهارت واقعی ما کجای زنجیره‌ی ارزش قرار داره؟ چقدر از ارزشی که خلق می‌کنیم حاصل توانایی خودمونه و چقدرش متکی به قابلیت‌هاییه که ابزارها در اختیارمون گذاشتن؟
و مهم‌تر از اون، آیا در حال یاد گرفتن رانندگی در مسیرهای ناشناخته هستیم، یا هنوز تمام اعتبار حرفه‌ای‌مون رو به عوض کردن دنده‌ای گره زدیم که ممکنه ماشین نسل بعدی اصلاً بهش نیازی نداشته باشه؟
🏁 پیست هنوز تموم نشده، مسابقه هم متوقف نمی‌شه. قرار نیست همه طراح موتور باشن، اما بهتره هرکدوم بدونیم چرا هنوز پشت فرمون نشستیم. | 512 |
| 3 | به عنوان یک معلم، یادگیری برای من امیده،
به عنوان یک پدر، یادگیری برای من مسیر نجات فرزندم از جهله،
و به عنوان یک انسان، یادگیری برای من حق طبیعیه که نباید به خاطر جبر جغرافیایی از کسی گرفته بشه.
در نهایت به عنوان یک دیجی کالایی،امروز دیجی کالا مهر برای من مسیر رسیدن به: امید یک معلم، مسیر نجات یک فرزند و احقاق حق اولیه یه انسانه.
ازتون میخوام در صورتی که امکانش رو دارید در پویش "هر جا که تویی" شرکت کنید و برای آینده کودکان کشورمون سهمی داشته باشید :
https://mehr.digikala.com/madrese-besaz/
@learning_with_m | 617 |
| 4 | سلام
مسعود دانش‌پور عزیز این پویش رو توی کانالش با قلم زیباش معرفی کرده؛ که فکر کنم لازم باشه تا جای ممکن از چنین پویش‌هایی حمایت کنیم.
اگر قرار بر فردای بهتری برای ایران باشه، این بهبود از پشت نیم‌کت‌ها خواهد بود، نه پشت تریبون‌ها. لذا هر کس از هر پویشی که به نحو صحیح به کودکان و خصوصا آموزش اون‌ها توجه داره؛ چه مدرسه صبح رویش باشه، چه قصه، رنگ، توپ؛ چه رعد؛ چه همین پویش دیجیکالا؛ کمک کنه، عملا به فردای بهتر ایران کمک کرده.
اگر به اعداد بخوایم نگاه کنیم هم: مطالعات مشهور جیمز هکمن و همکارانش درباره برنامه‌های باکیفیت در کودکی برای خانواده‌های محروم، بازدهی سرمایه‌گذاری اقتصادی بلندمدت حدود ۱۳.۷ درصد در سال رو برآورد کردن؛ منفعتی که فقط توی درآمد آینده خلاصه نمی‌شه و سلامت، آموزش و حتی کاهش جرم رو هم شامل می‌شه.
تخمین بانک جهانی هم به‌طور متوسط هر یک سال آموزش بیشتر، حدود ۱۰ درصد درآمد بیشتر در آینده رو میگه. یعنی کمک به آموزش یه کودک، اگر درست و مؤثر انجام بشه، صرفاً کمک به امروزش نیست؛ داریم روی چند دهه بعد یه جامعه سرمایه‌گذاری می‌کنیم.
پی‌نوشت ۱: دلیل کم‌کاری و مطلب نداشتن، مشغله کاری است، ولی سعی می‌کنم تا زودتر مطلب مربوط به Jev (از نگاه چرایی، معماری و تعاریف پایه‌ایش) رو جمع کنم. تا بعدش ببینیم کی فرصت می‌شه تا «آیا بیکار خواهیم شد» رو بنویسم. 😊
پی‌نوشت ۲: اگر در حوزه AI کار می‌کنید حواستون به اتفاقات مهم و ریلیزهای پیشِ رو در حوزه sandbox، memory، orchestration، subagents، باشه! غیب‌گویی نیست، ترند مقالاتی که دانشگاه‌های پیشرو یا هسته‌های تحقیقاتی گوگل و اوپن ای‌آی و... منتشر می‌کنن نشون میده بهینه‌سازی‌های بزرگی در راهه. اگر کسی علاقه‌مند پیام بده.
پی‌نوشت ۳: اگر توی لایه اپلیکیشن فعالید؛ حواستون به ریلیزهای هفته‌های پیشِ رو، مثل پستگرس ۱۹، دات‌نت ۱۱، Python 3.15 باشه؛ نه در حد آپدیت کردن، بلکه تغییرات مهم زیر پوسته‌ی اصلی... | 781 |
| 5 | ☑ چک‌لیست آماده‌سازی تیم، فرایندها و زیرساخت برای توسعه با AI
توجه: هیچ چک‌لیستی جهان‌شمول نیست؛ ولی می‌تونه بهانه و سرنخ‌هایی برای فکر کردن باشه.
توی این مطلب موضوعاتی رو که برای آماده‌سازی یک تیم توسعه نرم‌افزار (نه کارهای شخصی یا تجربی و...) برای توسعه با AI نیازه مرور کردم؛ اگر حوصله خوندن متن ندارید، به آخر متن مراجعه کنید.
🔗 لینک به مطلب کامل | 1 298 |
| 6 |  گوفر رو رنجوندید! شرم بر شما 😂
سومین بار بود این موضوع تحلیل عمیق GC جدید گو رو توی نظرسنجی‌ها گذاشتم؛ و زیباجویان عزیز نادیده گرفتید.
پکیج موفقیت و راز شادابی پوست ۱۷ رأی؛ مطلب به اون عمیق ۴ رأی!؟ | 1 006 |
| 7 | Немає тексту... | 1 010 |
| 8 | از زبون آمار: آیا 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 نیست؛ بلکه امر به درست استفاده کردنشه 😅
❤️ فایل گزارش کامل رو اگر دوست داشتید بخونید... | 5 156 |
| 9 |  Немає тексту... | 2 907 |
| 10 | ۱۳ سپتامبر، روز برنامه‌نویس... چی شد که برنامه‌نویس شدم!
برای هر کسی که به نحوی ذیل این عنوان شغلی جا می‌گیره؛ یه مشوق یا دلیل یا محرک اولیه وجود داشته که مرورش بعد از چند سال می‌تونه جالب باشه.
برای یکی رتبه کنکور بوده، برای یکی علاقه‌ای که یه معلم توی مدرسه براش ایجاد کرده، یکی دیگه شاید توسط یکی از اقوام و آشنایانش و...
برای من، چهارم ابتدایی رفتم (ثبت‌نامم کردن) کلاس برنامه‌نویسی، ولی حتی یک کلمه هم یاد نگرفتم! 😅 به معنی واقعی کلمه «هِچ!»
تا اینکه اول راهنمایی، توی سیلابس رسمی مدرسه، برنامه‌نویسی داشتیم، درس رسمی بود و فوق‌برنامه یا دل‌بخواه نبود، عین دروس رسمی هم سخت می‌گرفتن. خوبیش این بود که اصولی از اینکه کامپیوتر و نرم‌افزار قراره چی «مسئله‌ای» رو حل کنه شروع شد؛ بعدترش الگوریتم و فلوچارت، از شکستن مراحل کلی به جزئی و... بعد هم زبان لوگو روی کومودور؛ بعدش زبان قلم‌طراح، بعدش GW-Basic و... ولی کماکان یه درسی بود مثل ریاضی و علوم، با اینکه نمراتم خوب بود، ولی علاقه خاص و متفاوتی از بقیه درس‌ها نداشتم.
تا سوم راهنمایی: اون وقت‌ها سال تحصیلی ۳ تا ثُلث بود؛ برای پروژه درس برنامه‌نویسی ثُلث دوم به من «معادله درجه دوم در صورت دلتای منفی» رو دادن! اون وقت‌ها معادله درجه دوم رو اول دبیرستان درس می‌دادن، دلتای منفی رو هم می‌گفتن جواب نداره و برید سال اول دانشگاه یاد بگیرید. برای من چالش بزرگ، فهمیدن ذات معادله درجه دوم بود بعدش دلتای منفی و... باید وقت ناهار از ناظم نامه می‌گرفتم می‌رفتم کتابخونه‌ی دبیرستان بگردم ببینم اصلا چی به چیه!
سرتون رو درد نیارم؛ روزی که پروژه رو با زبان فورترن انجام دادم و با ذوق روی فلاپی ریختم و بردم تحویل دادم؛ تقریبا مطمئن بودم، این کاریه که دوست دارم توی زندگیم انجام بدم. و یه پروژه مدرسه، یه چالش که توسط یه معلم طرح شد، مسیر زندگی من رو شکل داد...
امروز بعد از گذشت این همه سال، من هنوز خیلی خوشحالم از این مسیر؛ و این خوشحالی ریشه و شروعش توی دانشگاه و محیط کار و مهاجرت شکل نگرفت؛ بلکه توی مدرسه و مقطع راهنمایی شکل گرفت؛ ای کاش حاکمان، خانواده‌ها، مدرسه‌ها؛ اهمیت فوق‌العاده‌ی مدرسه و خصوصا مقاطع پایین تحصیلی رو روی سرنوشت انسان‌های جامعه جدی‌تر می‌گرفتن و می‌فهمیدن میزان اثرگذاریش رو.
تنبلی نکنید و کامنت کنید چی باعث شد بیاید سمت نرم‌افزار 😊 ولو اینکه بگید جبر زمانه، شانس، رفیق بد و زغال مرغوب؛ حتماً جالبه!
اگر هم علاقه‌مند بودید در مورد اینکه «سرمایه‌گذاری قبل از دبستان از دانشگاه اثرگذارتره» بیشتر بدونید پیشنهاد می‌کنم تحقیقات Perry، Abecedarian و Heckman رو بخونید | 1 061 |
| 11 | لیدرشیپ فنی؛ یک انتخاب در مسیر رشد، یا گذرگاهی اجباری؟
مهندس خوبی بوده، پس مدیرش کنیم!
حقوق بیشتری می‌خواد؟ یه تیم هم بهش بدیم!
گاهی همین تصمیمِ ظاهراً خیرخواهانه، هم یک مهندس توانمند رو از کار موردعلاقه‌اش دور می‌کنه، هم یک تیم رو گرفتار.
توی این مطلب، اینکه قبل از پذیرفتن یا سپردن مسئولیت، چه چیزهایی رو باید بررسی کنیم رو نوشتم.
🔗 لینک مطلب
💬 خوشحال می‌شم نظر و نقدتون رو بخونم. | 1 037 |
| 12 | Немає тексту... | 1 048 |
| 13 | 🤖 بررسی Agent-First Development؛ چه کاری رو واگذار می‌کنیم، و از کجا می‌فهمیم می‌ارزه؟
ایجنت تست رو سبز کرده؛ ولی با ضعیف‌کردن خودِ تست! این مثال ساده، شروع مطلبی درباره Agent-First Development است. اینکه چجوری کار رو به Agent واگذار کنیم، درستیِ خروجیش رو بسنجیم و بفهمیم مجموع هزینهٔ اجرا و بازبینی واقعاً می‌ارزه؟
دربارهٔ شواهد بهره‌وری، مرز اختیار و تصمیم به ادامه‌دادن یا متوقف‌کردن هم نوشته‌ام. چون قرار نیست هر آزمایشی به استفادهٔ بیشتر از AI ختم بشه.
لینک مطالعه مطلب:
🔗 بررسی Agent-First Development
💬 نظر و تجربه‌تون رو اگر بنویسید خوشحال می‌شم. در ضمن موضوع بعدی، بر اساس آراء نظرسنجی در مورد پیش‌نیازهای لیدرشیپ خواهد بود؛ تا زمان نوشتنش اگر نکته یا سوالی دارید حتمن طرح کنید تا گپ بزنیم در موردش | 2 416 |
| 14 | 🎞 داستان 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، ده سال طول کشید! 😅
🎞 لینک یوتیوب | 1 385 |
| 15 | Немає тексту... | 1 277 |
| 16 | ⚡️ 🚩 داستان 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ی دیدید که هیچ‌کس نمی‌دونه چرا هنوز وجود داره، تجربه‌تون رو بنویسید؛ احتمالاً تنها نیستید! | 3 845 |
| 17 | حکایت چینی «کشیدن نهال برای اینکه زودتر رشد کنه» (拔苗助长)
۲۴۰۰ سال پیش، منسیوس فیلسوف چینی و از شاگردان مکتب کنفسیوس؛ از کشاورزی حکایت می‌کنه که از رشد آهسته نهال‌هایش کلافه شده بوده؛ و برای کمک به رشد سریع‌ترشون، شروع می‌کنه نهال‌ها رو از ساقه کمی به بالا می‌کشه. فردا می‌بینه همه نهال‌ها پژمرده شدن.
رشد و توسعه فردی و کاری رو هم نمی‌شه با جلو انداختن مرحله‌ی بعدی تسریع کرد. بعضی وقت‌ها این کار، فرایند رشد رو خراب می‌کنه.
💡مراقب باشیم آدم‌ها رو با ارتقاء نابه‌هنگام خراب نکنیم؛ و مراقب باشیم آدم‌های دیگه بر اساس شناخت کم؛ تصورات غیردقیق؛ یا حتی برای تسریع رسیدن به هدف‌های خودشون؛ با ارتقاء زودهنگام ما، جلو رشدمون رو نگیرن! (سیب کال رو از درخت نچینیم؛ چون نه قابل استفاده خواهد بود، و نه فرصت رسیدن رو خواهد داشت).
اگر دوست داشتید بیشتر بخونید:
- Peter Principle
- Law of the Farm
- HiPo Derailment
- Zone of proximal development (منطقه مجاور رشد, این موضوع مهمیه)
- Shu Ha Ri | 2 158 |
| 18 | 🖊 وایب‌گاورنینگ چیست؟
کوتاه: یک عبارت من‌درآوردی که خودم ساختم!
متوسط: همون وایب‌کدینگ، ولی در حوزه‌ی سیاست‌گذاری و حکمرانی.
بلند:
توی وایب‌کدینگ، آقاهه چیزی رو که دوست داره به ماشین میگه و ماشین هم با هزار بدبختی و خرابکاری بالاخره یه چیزی براش می‌سازه. مشکل هم از جایی شروع می‌شه که بعداً هر بار آقاهه می‌خواد ابروش رو درست کنه، می‌زنه یه چشمش رو کور می‌کنه! چون نه واقعاً می‌دونه چی ساخته شده، نه رفتار سیستم رو درست می‌فهمه و نه خروجی به‌سادگی قابل نگهداری و اصلاحه.
توی وایب‌گاورنینگ هم تقریباً همین اتفاق می‌افته، فقط به‌جای کد، پای سیاست، اقتصاد، مسائل اجتماعی یا حتی اداره‌ی یک شرکت خصوصی در میونه.
آقاهه یه چیزی رو که دوست داره، میگه، درست مثل یه پرامپت. بعد سازوکاری که از قدرت آقاهه حساب می‌بره، موظف می‌شه با هر ضرب و زور و هزینه‌ای، اجراش کنه، در عمل شبیه همون کاریه که مدل هوش مصنوعی می‌کنه.
ولی مسئله اینجاست که نه لزوماً درکی از سازوکار سیستم وجود داره، نه روابط علت و معلولی درست فهمیده شدن، نه اثرات جانبی قابل پیش‌بینی هستن و نه همیشه چیزی به اسم rollback وجود داره.
توی وایب‌کدینگ اگه نفهمی چی ساختی، نهایتاً ممکنه یه نرم‌افزار رو خراب کنی.
توی وایب‌گاورنینگ، production خود جامعه ست، userها حق opt-out ندارن و rollback هم پرهزینه، دشوار یا حتی غیرممکنه.
حالا پند و اندرز اخلاقی:
هرچه می‌خواهی بگو و هرچه می‌خواهی بکن، اما کاری را که نمی‌فهمی، با قدرت به دیگران تحمیل نکن.
وایب‌کدینگ بکن، می بخور، منبر بسوزان...
ولی وایب‌گاورنینگ مکن!
پی‌نوشت ۱: وقتی آخر شب توییتر رو باز می‌کنی می‌بینی دلار شده فلان عدد؛ لینکدین رو باز می‌کنی و چپ و راست حلقه سبز می‌بینی، یه روز در میون یه بانک هک می‌شه... اولین ربطی که به ذهنت میاد شباهت وایب‌کدینگ و وایب‌گاورنینگه؛ عدم درک از مکانیزم‌ها.
پی‌نوشت ۲: توی وایب‌کدینگ؛ مدل هوش مصنوعی «نه» نمی‌گه. گند می‌زنه، اشتباه می‌کنه، ولی ذاتا با وایب‌کدر درگیر نمی‌شه و اصطکاکی نداره؛ توی جامعه اما باید اصطکاک (از نوع سازنده) وجود داشته باشه: نقد صحیح و سازنده، نهاد، تخصص، سازمان، رسانه، داده و خصوصا حس مسئولیت و دلسوزی نسبت به نتیجه‌ی تصمیم.
اینا به‌نوعی compiler و type checker حکمرانی‌ان.
هرچقدر هم این سازوکارهای مدنی ضعیف‌تر بشن، اجرای یک پرامپت بد راحت‌تر می‌شه. و شاید تعریف دقیق‌تر وایب‌گاورنینگ همین باشه: قدرت زیاد، اصطکاک کم، و فهم ناکافی از سیستمی که داری تغییرش می‌دی. | 1 518 |
| 19 | Немає тексту... | 4 530 |
| 20 | در مورد Spec Driven Development | 1 268 |
