نمونه کاربردهای هوش مصنوعی
به تازگی گوگل در یک وبنوشت، مجموعهای از نمونه کاربردهای هوش مصنوعی را معرفی کرده است. این نوشته شامل ۳۲۱ نمونهی کاربردی از حوزههای مختلفی مانند خردهفروشی و کالاهای مصرفی، خودرو و لجستیک، سلامت است. مرور این نوشته برای آشنایی با کابردهای هوش مصنوعی و همچنین ایده گرفتن برای شناسایی کاربردهای مشابه در حوزهی تخصصی میتواند مفید باشد.
https://cloud.google.com/transform/101-real-world-generative-ai-use-cases-from-industry-leaders
https://news.1rj.ru/str/bibalan_com
https://bibalan.com/?p=4709
به تازگی گوگل در یک وبنوشت، مجموعهای از نمونه کاربردهای هوش مصنوعی را معرفی کرده است. این نوشته شامل ۳۲۱ نمونهی کاربردی از حوزههای مختلفی مانند خردهفروشی و کالاهای مصرفی، خودرو و لجستیک، سلامت است. مرور این نوشته برای آشنایی با کابردهای هوش مصنوعی و همچنین ایده گرفتن برای شناسایی کاربردهای مشابه در حوزهی تخصصی میتواند مفید باشد.
https://cloud.google.com/transform/101-real-world-generative-ai-use-cases-from-industry-leaders
https://news.1rj.ru/str/bibalan_com
https://bibalan.com/?p=4709
👍14
مهم نیست که چه میخواهیم!
صحنهای از مجموعه تلویزیونی “بازی تاج و تخت” (Game of Thrones) است که توی اون «لیتل فینگر» (شخصیت مرموز، حیلهگر و تشنهی قدرت این سریال) رو به «سانسا استارک» میکنه و میگه:
«همیشه دلم میخواست یه کشتی داشته باشم. ولی الان [که یه کشتی دارم] دلم میخواد چند تا کشتی داشته باشم. عجیبه! مگه نه؟!»
و سانسا ازش میپرسه: «چی عجیبه؟»
و بعد لیتل فینگر ادامه میده: «مهم نیست که چی میخوایم. مهم اینه که وقتی به دستاش میآریم یه چیز دیگه میخوایم.»
https://bit.ly/3BP3a5L
https://news.1rj.ru/str/bibalan_com
https://bibalan.com/?p=4712
صحنهای از مجموعه تلویزیونی “بازی تاج و تخت” (Game of Thrones) است که توی اون «لیتل فینگر» (شخصیت مرموز، حیلهگر و تشنهی قدرت این سریال) رو به «سانسا استارک» میکنه و میگه:
«همیشه دلم میخواست یه کشتی داشته باشم. ولی الان [که یه کشتی دارم] دلم میخواد چند تا کشتی داشته باشم. عجیبه! مگه نه؟!»
و سانسا ازش میپرسه: «چی عجیبه؟»
و بعد لیتل فینگر ادامه میده: «مهم نیست که چی میخوایم. مهم اینه که وقتی به دستاش میآریم یه چیز دیگه میخوایم.»
https://bit.ly/3BP3a5L
https://news.1rj.ru/str/bibalan_com
https://bibalan.com/?p=4712
❤5👍3
روانشناسی پول
کتاب روانشناسی پول: درسهای ابدی دربارهی ثروت، طمع و خوشحالی (The Psychology of Money: Timeless lessons on wealth, greed, and happiness) را به همراه چند تن از دوستان عزیزم خواندم.
مورگان هاوسل در این کتاب، شیوهی تفکر، مدیریت و برخورد افراد با پول را بررسی میکند. به جای تاکید بر جنبههای فنی و تکنیکال، نویسنده به بررسی جنبههای رفتاری و احساسی انسانها میپردازد و با کمک گرفتن از مباحث روانشناسی، واقعیات تاریخی و تجربیات شخصی تلاش میکند نشان دهد که موفقیت مالی بیشتر از آن که به هوش یا دانش فنی انسانها وابسته باشد، به رفتار، رویکردها و ارزشهای فردی انسانها بر میگردد.
در این کتاب شما هیچ نشانهای از راهکارهای حاضر و آماده یا توصیههای مالی یا تکنیکی پیدا نمیکنید. تجربهی من از خواندن این کتاب، «یادگیری صورت مسالههای مهم»، «فراگیری ابعاد مساله به ویژه از جنبههای روانشناختی» و «به چالش کشیده شدن باورها و آموختهها» بود.
اجازه دهید بدون لو دادن مطالب کتاب، چند نمونه را با هم بررسی کنیم.
– در این کتاب توضیح میدهد که پولداری (rich) با ثروتمندی (wealthy) تفاوت دارد و آن چه باید به دنبال آن بود ثروتمندی است!
– جای دیگر کتاب دربارهی مفهومی به نام «کافی بودن» (enough) توضیح میدهد و تاکید میکند که «مقدار کافی بودن» موضوعی است شخصی و بعد توضیح میدهد که چگونه میتوان از این مفهوم برای «آزادی مالی» استفاده کرد.
– در بخش دیگری از کتاب نیز بیان میدهد که حواستان به آفت «تو – من» باشد. مشاوران سرمایهگذاری اعم از حرفهای یا آماتور وقتی توصیه میکنند معمولن شرایط خودشان یا شرایط خاصی را برای سرمایهگذار در نظر میگیرند. باید مراقب باشید شرایط شما ممکن است با افراد مد نظر مشاوران متفاوت باشد.
کتاب روانشناسی پول از آن دسته کتابهایی است که هر چند وقت یک بار باید دوباره آن را خواند. مهمتر این که میتوان برای هر فصل کتاب جلسههای بحث و هماندیشی گذاشت که بیشک به چالش ختم خواهد شد ;).
سپاسگزار دوستان عزیزم هستم که بانی و بهانهای شدند برای خواندن این کتاب ارزشمند.
گزیده:
انسانها کارهای احمقانهای با پول میکنند ولی هیچ انسانی احمق نیست!
مورگان هاوسل – روانشناسی پول
https://bit.ly/4h3fpdL
https://news.1rj.ru/str/bibalan_com
https://bibalan.com/?p=4719
کتاب روانشناسی پول: درسهای ابدی دربارهی ثروت، طمع و خوشحالی (The Psychology of Money: Timeless lessons on wealth, greed, and happiness) را به همراه چند تن از دوستان عزیزم خواندم.
مورگان هاوسل در این کتاب، شیوهی تفکر، مدیریت و برخورد افراد با پول را بررسی میکند. به جای تاکید بر جنبههای فنی و تکنیکال، نویسنده به بررسی جنبههای رفتاری و احساسی انسانها میپردازد و با کمک گرفتن از مباحث روانشناسی، واقعیات تاریخی و تجربیات شخصی تلاش میکند نشان دهد که موفقیت مالی بیشتر از آن که به هوش یا دانش فنی انسانها وابسته باشد، به رفتار، رویکردها و ارزشهای فردی انسانها بر میگردد.
در این کتاب شما هیچ نشانهای از راهکارهای حاضر و آماده یا توصیههای مالی یا تکنیکی پیدا نمیکنید. تجربهی من از خواندن این کتاب، «یادگیری صورت مسالههای مهم»، «فراگیری ابعاد مساله به ویژه از جنبههای روانشناختی» و «به چالش کشیده شدن باورها و آموختهها» بود.
اجازه دهید بدون لو دادن مطالب کتاب، چند نمونه را با هم بررسی کنیم.
– در این کتاب توضیح میدهد که پولداری (rich) با ثروتمندی (wealthy) تفاوت دارد و آن چه باید به دنبال آن بود ثروتمندی است!
– جای دیگر کتاب دربارهی مفهومی به نام «کافی بودن» (enough) توضیح میدهد و تاکید میکند که «مقدار کافی بودن» موضوعی است شخصی و بعد توضیح میدهد که چگونه میتوان از این مفهوم برای «آزادی مالی» استفاده کرد.
– در بخش دیگری از کتاب نیز بیان میدهد که حواستان به آفت «تو – من» باشد. مشاوران سرمایهگذاری اعم از حرفهای یا آماتور وقتی توصیه میکنند معمولن شرایط خودشان یا شرایط خاصی را برای سرمایهگذار در نظر میگیرند. باید مراقب باشید شرایط شما ممکن است با افراد مد نظر مشاوران متفاوت باشد.
کتاب روانشناسی پول از آن دسته کتابهایی است که هر چند وقت یک بار باید دوباره آن را خواند. مهمتر این که میتوان برای هر فصل کتاب جلسههای بحث و هماندیشی گذاشت که بیشک به چالش ختم خواهد شد ;).
سپاسگزار دوستان عزیزم هستم که بانی و بهانهای شدند برای خواندن این کتاب ارزشمند.
گزیده:
انسانها کارهای احمقانهای با پول میکنند ولی هیچ انسانی احمق نیست!
مورگان هاوسل – روانشناسی پول
https://bit.ly/4h3fpdL
https://news.1rj.ru/str/bibalan_com
https://bibalan.com/?p=4719
👍6👏3🤔1🎉1
برنامهنویسی دلی! – بخش یک
پیشگفتار یک: نگاه ریاضیگونه و نگاه مهندسیگونه به برنامهنویسی
به گذشته که نگاه میکنم میبینم که آموزش برنامهنویسی همراه بوده با نوعی نگاه که بیشباهت به حل مسالههای ریاضی یا فیزیک نیست. نوعی نگاه حذف جزییات در ابتدا و اضافه کردن جزییات در ادامه.
برای نمونه در نگاه ریاضیگونه به برنامهنویسی شما ابتدا باید ساختار دادهها (data structure) را تعیین کنید و بعد با نگاه رویهگونه و الگوریتمی به کمک تابع یا رویه (procedure or function) راهحلتان را به گامهایی بشکنید و همین گامها را تکرار کنید. روی کاغذ، در کامپیوتر یا در ذهنتان، ابتدا باید این اجزا فکر کنید و بعد کدنویسی رو شروع کنید. البته میتوانید کمی فکر کنید و بعد کد بنویسید و بعد باز هم فکر کنید و کد بنویسید و …
در نگاه مهندسی هم برای نمونه در مدل آبشاری (waterfall) تلاش بر این است که قبل از ورود به جزییات و کدنویسی، طرحی از راه حل آماده شده باشد و به اندازه کافی پخته شده باشد تا هزینه پیادهسازی و ورود به جزییات کاهش پیدا کند. بماند که در این رویکرد تاکید بر این است که تا جای ممکن قبل از شروع پیادهسازی به همه چیز فکر کنید.
از این منظر، نگرش روشهای تکراری-تدریجی (iterative-incremental) نیز همین گونه است فقط «به همه چیز فکر کن بعد کد بنویس» به «یک کم فکر کن یک کم کد بنویس بعد دوباره فکر کن …». تلاش بر این است که اندازه و مدت آماده کردن طراحی و سپس پیادهسازی آن کاهش پیدا کند.
رویکرد توسعهی آزمون محور (Test Driven Development) به شکلی خلاقانه به جای شروع از «فکر کردن»، با نگاه صرفن کدنویسی، تلاش میکند تا ابتدا طرح کلان را از لا به لای آزمونهایی که به صورت کد نوشته میشود بیرون بیاورد. یادآوری این نکته مهم است که یکی از نتایج دوستداشتنی توسعهی آزمون محور این است که شما برای نوشتن آزمونها باید به طراحی کدی که میخواهید بنویسید فکر کنید. ولی در هر صورت باید «قبل از پیادهسازی فکر کنید»
برداشت من این است که اگر از این منظر به روشهای توسعهی نرمافزار نگاه کنیم همهی آنها بر این بنیان استوارند که «اول فکر کن بعد کد بنویس»!
در یکی دو نوشتهی بعدی در نظر دارم کمی در این باره بنویسم و ایدهای را با شما مطرح کنم.
گزیده:
برنامهنویس کیه؟
برنامهنویس، ماشینی یه که قهوه [ یا چایی] رو به کد تبدیل میکنه!
https://bit.ly/4g1BmsJ
https://news.1rj.ru/str/bibalan_com
https://bibalan.com/?p=4706
پیشگفتار یک: نگاه ریاضیگونه و نگاه مهندسیگونه به برنامهنویسی
به گذشته که نگاه میکنم میبینم که آموزش برنامهنویسی همراه بوده با نوعی نگاه که بیشباهت به حل مسالههای ریاضی یا فیزیک نیست. نوعی نگاه حذف جزییات در ابتدا و اضافه کردن جزییات در ادامه.
برای نمونه در نگاه ریاضیگونه به برنامهنویسی شما ابتدا باید ساختار دادهها (data structure) را تعیین کنید و بعد با نگاه رویهگونه و الگوریتمی به کمک تابع یا رویه (procedure or function) راهحلتان را به گامهایی بشکنید و همین گامها را تکرار کنید. روی کاغذ، در کامپیوتر یا در ذهنتان، ابتدا باید این اجزا فکر کنید و بعد کدنویسی رو شروع کنید. البته میتوانید کمی فکر کنید و بعد کد بنویسید و بعد باز هم فکر کنید و کد بنویسید و …
در نگاه مهندسی هم برای نمونه در مدل آبشاری (waterfall) تلاش بر این است که قبل از ورود به جزییات و کدنویسی، طرحی از راه حل آماده شده باشد و به اندازه کافی پخته شده باشد تا هزینه پیادهسازی و ورود به جزییات کاهش پیدا کند. بماند که در این رویکرد تاکید بر این است که تا جای ممکن قبل از شروع پیادهسازی به همه چیز فکر کنید.
از این منظر، نگرش روشهای تکراری-تدریجی (iterative-incremental) نیز همین گونه است فقط «به همه چیز فکر کن بعد کد بنویس» به «یک کم فکر کن یک کم کد بنویس بعد دوباره فکر کن …». تلاش بر این است که اندازه و مدت آماده کردن طراحی و سپس پیادهسازی آن کاهش پیدا کند.
رویکرد توسعهی آزمون محور (Test Driven Development) به شکلی خلاقانه به جای شروع از «فکر کردن»، با نگاه صرفن کدنویسی، تلاش میکند تا ابتدا طرح کلان را از لا به لای آزمونهایی که به صورت کد نوشته میشود بیرون بیاورد. یادآوری این نکته مهم است که یکی از نتایج دوستداشتنی توسعهی آزمون محور این است که شما برای نوشتن آزمونها باید به طراحی کدی که میخواهید بنویسید فکر کنید. ولی در هر صورت باید «قبل از پیادهسازی فکر کنید»
برداشت من این است که اگر از این منظر به روشهای توسعهی نرمافزار نگاه کنیم همهی آنها بر این بنیان استوارند که «اول فکر کن بعد کد بنویس»!
در یکی دو نوشتهی بعدی در نظر دارم کمی در این باره بنویسم و ایدهای را با شما مطرح کنم.
گزیده:
برنامهنویس کیه؟
برنامهنویس، ماشینی یه که قهوه [ یا چایی] رو به کد تبدیل میکنه!
https://bit.ly/4g1BmsJ
https://news.1rj.ru/str/bibalan_com
https://bibalan.com/?p=4706
👍15
برنامهنویسی دلی! – بخش دو
فیلم «پیدا کردن فارستر» (Finding Forrester) به داستان آشنایی یک رماننویس معروف، برندهی جایزه پولیتزر و البته منزوی به نام ویلیام فارستر (با بازی شان کانری) و یک نوجوان دبیرستانی به نام جمال میپردازد. فارستر پس از آن که پی میبرد جمال برای پذیرفته شدن در کالج نیاز دارد متنی ادبی بنویسد، تصمیم میگیرد به او کمک کند. متن زیر گفتگوی فارستر و جمال است در اولین تلاش فارستر برای کمک به جمال. در این صحنه، فارستر پشت یک ماشین تحریر مینشیند و جمال هم رو به روی او و جلوی یک ماشین تحریر دیگر ایستاده است.
فارستر: پس بیا به اون [یکی از استادهای دانشگاه و عضو کمیته ارزشیابی] نشون بدیم که تو چه کاری میتونی انجام بدی.
جمال: چرا چیزهایی که برای خودمون مینویسیم … همیشه خیلی بهتر از چیزهاییاند که برای دیگران مینویسیم؟
فارستر: زود باش.
– بشین.
– شروع کن.
جمال: چی رو شروع کنم؟
فارستر: نوشتن رو
در این لحظه، فارستر شروع به تایپ میکنه.
جمال: داری چه کار میکنی؟
فارستر: دارم مینویسم، همون کاری که تو قراره بکنی… وقتی که شروع کنی به فشردن اون کلیدها [ی ماشین تحریر].
در اینجا، جمال که پشت ماشین تحریر نشسته، بدون اینکه چیزی تایپ کنه مشغول فکر کردن میشه.
فارستر: چیزی شده؟
جمال: نه. فقط دارم فکر میکنم.
فارستر: نه. فکر کردن ممنوعه. فکر کردن برای بعدنه.
– پیشنویس اولت رو با قلبت مینویسی…
– و بعد با عقلت بازنویسی میکنی
– اولین اصل نوشتن … نوشتنه، نه فکر کردن
جمال: خدایا.
گزیده:
ما از رویاهایمان دست میکشیم چون میترسیم در رسیدن به آنها شکست بخوریم و بدتر این که آنها را رها میکنیم چون میترسیم به آنها برسیم.
ویلیام فارستر در فیلم پیدا کردن فارستر
https://bit.ly/4g1BmsJ
https://news.1rj.ru/str/bibalan_com
https://bibalan.com/?p=4738
فیلم «پیدا کردن فارستر» (Finding Forrester) به داستان آشنایی یک رماننویس معروف، برندهی جایزه پولیتزر و البته منزوی به نام ویلیام فارستر (با بازی شان کانری) و یک نوجوان دبیرستانی به نام جمال میپردازد. فارستر پس از آن که پی میبرد جمال برای پذیرفته شدن در کالج نیاز دارد متنی ادبی بنویسد، تصمیم میگیرد به او کمک کند. متن زیر گفتگوی فارستر و جمال است در اولین تلاش فارستر برای کمک به جمال. در این صحنه، فارستر پشت یک ماشین تحریر مینشیند و جمال هم رو به روی او و جلوی یک ماشین تحریر دیگر ایستاده است.
فارستر: پس بیا به اون [یکی از استادهای دانشگاه و عضو کمیته ارزشیابی] نشون بدیم که تو چه کاری میتونی انجام بدی.
جمال: چرا چیزهایی که برای خودمون مینویسیم … همیشه خیلی بهتر از چیزهاییاند که برای دیگران مینویسیم؟
فارستر: زود باش.
– بشین.
– شروع کن.
جمال: چی رو شروع کنم؟
فارستر: نوشتن رو
در این لحظه، فارستر شروع به تایپ میکنه.
جمال: داری چه کار میکنی؟
فارستر: دارم مینویسم، همون کاری که تو قراره بکنی… وقتی که شروع کنی به فشردن اون کلیدها [ی ماشین تحریر].
در اینجا، جمال که پشت ماشین تحریر نشسته، بدون اینکه چیزی تایپ کنه مشغول فکر کردن میشه.
فارستر: چیزی شده؟
جمال: نه. فقط دارم فکر میکنم.
فارستر: نه. فکر کردن ممنوعه. فکر کردن برای بعدنه.
– پیشنویس اولت رو با قلبت مینویسی…
– و بعد با عقلت بازنویسی میکنی
– اولین اصل نوشتن … نوشتنه، نه فکر کردن
جمال: خدایا.
گزیده:
ما از رویاهایمان دست میکشیم چون میترسیم در رسیدن به آنها شکست بخوریم و بدتر این که آنها را رها میکنیم چون میترسیم به آنها برسیم.
ویلیام فارستر در فیلم پیدا کردن فارستر
https://bit.ly/4g1BmsJ
https://news.1rj.ru/str/bibalan_com
https://bibalan.com/?p=4738
❤7👍3
بختک!
تو شبِ سیا
تو شبِ تاریک
از چپ و از راست
از دور و نزدیک
یه نفر داره
جار میزنه، جار:
آهای غمی که
مثلِ یه بختک
رو سینهی من
شدهای آوار
از گلوی من
دستاتو، وردار
شعر خاله یادگار از حسین منزوی
با صدای شاعر
https://youtu.be/UfkoIF6I-Og?si=UhUaJ9f-GQs_XxM_
https://news.1rj.ru/str/bibalan_com
https://bibalan.com/?p=4763
تو شبِ سیا
تو شبِ تاریک
از چپ و از راست
از دور و نزدیک
یه نفر داره
جار میزنه، جار:
آهای غمی که
مثلِ یه بختک
رو سینهی من
شدهای آوار
از گلوی من
دستاتو، وردار
شعر خاله یادگار از حسین منزوی
با صدای شاعر
https://youtu.be/UfkoIF6I-Og?si=UhUaJ9f-GQs_XxM_
https://news.1rj.ru/str/bibalan_com
https://bibalan.com/?p=4763
❤5😢5
کتاب «چگونه تصمیم بگیریم»
https://bit.ly/3YRBK7u
همان طور که قبلن نوشتم، در یک گروه کوچک و دوستانه کتابهایی را به شیوهی «آهسته و پیوسته» میخوانیم و با هم در مورد آنها گفتگو میکنیم. این بار نوبت به کتاب «چگونه تصمیم بگیریم: ابزارهای ساده برای انتخابهای بهتر» (How to Decide: Simple Tools for Making Better Choices) اثر آنی دوک (Annie Duke) رسید.
نویسنده کتاب هم یک پوکرباز حرفهای و هم یک پژوهشگر و دانشآموختهی حوزهی تصمیمگیری است و با تکیه بر دانش و تجربهی خود تلاش میکند تا به بهبود مهارت تصمیمگیری خوانندگان کمک کند. کتاب با ارائه تمرینها و پرسشهای عملی، به خواننده کمک میکند تا خطاهای شناختی و سوگیریهای ذهنی خود را شناسایی و اصلاح کند. نویسنده مفاهیمی مانند نقش شانس در نتایج، اهمیت بازخورد باکیفیت و تمایز بین کیفیت تصمیم و نتیجه را به زبانی ساده و قابل فهم شرح میدهد.
این کتاب برای من که علاقهی فراوانی به حوزهی تصمیمگیری و خطاهای شناختی دارم، کتابی بسیار آموزنده بود. هر چند جاهایی خواندنش برای من خستهکننده میشد، با این حال از آن دست کتابهایی است که باید دوباره نگاهی به آن بیندازم یا دست کم باید بخش خلاصهی پایان هر فصل آن را برای یادآوری دوباره بخوانم. اگر فرصت نمیکنید کتاب را بخوانید پیشنهاد میکنم نگاهی به بخش خطای شناختی «نتیجهگرایی» (resulting) بیندازید.
گزیده:
کیفیت نتایج یک تصمیم مانعی است در برابر توانایی درک ما از کیفیت آن تصمیم. آنی دوک
The quality of the outcome casts a shadow over our ability to see the quality of the decision.
توضیح: این جمله بدین معناست که معمولاً قضاوت ما از کیفیت (درستی/نادرستی) تصمیمها بر اساس نتایج آنهاست. اگر نتیجهی تصمیم خوب باشد، فکر میکنیم تصمیم خوبی گرفتهایم و اگر نتیجه بد باشد، تصور میکنیم تصمیم بدی گرفتهایم. در حالی که چنین رویکردی همیشه درست نیست.
https://news.1rj.ru/str/bibalan_com
https://bibalan.com/?p=4766
https://bit.ly/3YRBK7u
همان طور که قبلن نوشتم، در یک گروه کوچک و دوستانه کتابهایی را به شیوهی «آهسته و پیوسته» میخوانیم و با هم در مورد آنها گفتگو میکنیم. این بار نوبت به کتاب «چگونه تصمیم بگیریم: ابزارهای ساده برای انتخابهای بهتر» (How to Decide: Simple Tools for Making Better Choices) اثر آنی دوک (Annie Duke) رسید.
نویسنده کتاب هم یک پوکرباز حرفهای و هم یک پژوهشگر و دانشآموختهی حوزهی تصمیمگیری است و با تکیه بر دانش و تجربهی خود تلاش میکند تا به بهبود مهارت تصمیمگیری خوانندگان کمک کند. کتاب با ارائه تمرینها و پرسشهای عملی، به خواننده کمک میکند تا خطاهای شناختی و سوگیریهای ذهنی خود را شناسایی و اصلاح کند. نویسنده مفاهیمی مانند نقش شانس در نتایج، اهمیت بازخورد باکیفیت و تمایز بین کیفیت تصمیم و نتیجه را به زبانی ساده و قابل فهم شرح میدهد.
این کتاب برای من که علاقهی فراوانی به حوزهی تصمیمگیری و خطاهای شناختی دارم، کتابی بسیار آموزنده بود. هر چند جاهایی خواندنش برای من خستهکننده میشد، با این حال از آن دست کتابهایی است که باید دوباره نگاهی به آن بیندازم یا دست کم باید بخش خلاصهی پایان هر فصل آن را برای یادآوری دوباره بخوانم. اگر فرصت نمیکنید کتاب را بخوانید پیشنهاد میکنم نگاهی به بخش خطای شناختی «نتیجهگرایی» (resulting) بیندازید.
گزیده:
کیفیت نتایج یک تصمیم مانعی است در برابر توانایی درک ما از کیفیت آن تصمیم. آنی دوک
The quality of the outcome casts a shadow over our ability to see the quality of the decision.
توضیح: این جمله بدین معناست که معمولاً قضاوت ما از کیفیت (درستی/نادرستی) تصمیمها بر اساس نتایج آنهاست. اگر نتیجهی تصمیم خوب باشد، فکر میکنیم تصمیم خوبی گرفتهایم و اگر نتیجه بد باشد، تصور میکنیم تصمیم بدی گرفتهایم. در حالی که چنین رویکردی همیشه درست نیست.
https://news.1rj.ru/str/bibalan_com
https://bibalan.com/?p=4766
👍11
هوش مصنوعی: با هم یاد بگیریم (۱)
پیش گفتار:
در این نوشتهها میخواهم منابعی برای آشنایی کاربردی با هوش مصنوعی را معرفی کنم. مخاطبان اصلی این نوشتهها، توسعهدهندگان نرمافزار هستند و تمرکز بر هوش مصنوعی مولد (Gen AI) خواهد بود. تلاش میکنم مفاهیم و مباحث فنیتر این حوزه تا جایی که به کاربرد بهتر کمک کند در منابع گنجانده شود. اولویت در انتخاب منابع بر منابع ویدیویی خواهد بود.
ایدهی نوشتن این نوشتهها از یکی از جلسات دوستانهی هفتگی آمده. در یک تصمیم گروهی، قرار شد که دربارهی هوش مصنوعی با هم یاد بگیریم و بیشتر بدانیم. با توجه به آشناییام به این حوزه، انتخاب مطالب و مسیر یادگیری بر عهدهی من گذاشته شده. در نتیجه این دسته از نوشتهها به موازات یا بعد از آن جلسات نوشته خواهد شد.
لطفن اگر منابعی در این زمینه میشناسید به من معرفی کنید. پیشاپیش سپاسگزارم.
درس ۱: پرامپتنویسی
منبع: Master the Perfect ChatGPT Prompt Formula
آدرس:
https://www.youtube.com/watch?v=jC4v5AS4RIM
گزیده:
قبلن استکاورفلو (stackoverflow) همیشه جلوی من باز بود و ازش برای برنامهنویسی استفاده میکردم. الان به جاش چت GenAI جلوم بازه ولی اصلن احساس نمیکنم یک برنامهنویسام. احساس میکنم شدم یک مدیر میانی که باید مودبانه و با خواهش از کارآموز نابغه و غیرقابل پیشبینیام بخوام که «لطفن رنگ اون دکمه (button) توی فرم رو آبیش کن»
به نقل از خود GenAI
https://news.1rj.ru/str/bibalan_com
https://bibalan.com/?p=4771
پیش گفتار:
در این نوشتهها میخواهم منابعی برای آشنایی کاربردی با هوش مصنوعی را معرفی کنم. مخاطبان اصلی این نوشتهها، توسعهدهندگان نرمافزار هستند و تمرکز بر هوش مصنوعی مولد (Gen AI) خواهد بود. تلاش میکنم مفاهیم و مباحث فنیتر این حوزه تا جایی که به کاربرد بهتر کمک کند در منابع گنجانده شود. اولویت در انتخاب منابع بر منابع ویدیویی خواهد بود.
ایدهی نوشتن این نوشتهها از یکی از جلسات دوستانهی هفتگی آمده. در یک تصمیم گروهی، قرار شد که دربارهی هوش مصنوعی با هم یاد بگیریم و بیشتر بدانیم. با توجه به آشناییام به این حوزه، انتخاب مطالب و مسیر یادگیری بر عهدهی من گذاشته شده. در نتیجه این دسته از نوشتهها به موازات یا بعد از آن جلسات نوشته خواهد شد.
لطفن اگر منابعی در این زمینه میشناسید به من معرفی کنید. پیشاپیش سپاسگزارم.
درس ۱: پرامپتنویسی
منبع: Master the Perfect ChatGPT Prompt Formula
آدرس:
https://www.youtube.com/watch?v=jC4v5AS4RIM
گزیده:
قبلن استکاورفلو (stackoverflow) همیشه جلوی من باز بود و ازش برای برنامهنویسی استفاده میکردم. الان به جاش چت GenAI جلوم بازه ولی اصلن احساس نمیکنم یک برنامهنویسام. احساس میکنم شدم یک مدیر میانی که باید مودبانه و با خواهش از کارآموز نابغه و غیرقابل پیشبینیام بخوام که «لطفن رنگ اون دکمه (button) توی فرم رو آبیش کن»
به نقل از خود GenAI
https://news.1rj.ru/str/bibalan_com
https://bibalan.com/?p=4771
YouTube
Master the Perfect ChatGPT Prompt Formula (in just 8 minutes)!
Grab my AI Toolkit for free: https://academy.jeffsu.org/ai-toolkit?utm_source=youtube&utm_medium=video&utm_campaign=139
Download my favorite prompts for productivity: https://academy.jeffsu.org/workspace-toolkit?utm_source=youtube&utm_medium=video&utm_campaign=139…
Download my favorite prompts for productivity: https://academy.jeffsu.org/workspace-toolkit?utm_source=youtube&utm_medium=video&utm_campaign=139…
👍15
هوش مصنوعی: با هم یاد بگیریم (۲)
https://bit.ly/43dytki
در این بخش میخواهیم با هم یاد بگیریم که چگونه یک متن به یک بردار تبدیل میشود. تبدیل متن به بردار یکی از پایهای ترین و مهمترین کارها در پردازش زبان طبیعی و یادگیری ماشین است.
با تبدیل متن به بردار میتوان بخش عمدهای از عملیات مورد نیاز برای پردازش زبان طبیعی به عملیات روی بردارها تبدیل میشود. برای درک این موضوع اجازه دهید مثالی از درس فیزیک را با هم مرور کنیم.
در مبحث حرکت در درس فیزیک، نقطهای را به عنوان مبدا در نظر میگرفتیم. موقعیت متحرک را هم روی محور افقی (محور ایکس) نشان میدادیم. مثلن اگر متحرک در سمت راست مبدا مختصات و به فاصله ۵ متری آن بود آن را به صورت بردار مثبت ۵ (+۵) نشان میدادیم. اگر متحرک به اندازه ۷ متر به سمت چپ حرکت میکرد، میزان جابهجایی آن را به صورت بردار منفی ۷ (-۷) نشان میدادیم. برای پیدا کردن مقصد متحرک کافی است که دو بردار +۵ و -۷ یعنی مبدای حرکت و میزان جا به جایی متحرک را با هم جمع کنیم تا به مقصد یعنی منفی ۲ (-۲) برسیم. در اینجا اگر سه متحرک الف، ب، پ داشته باشیم که بردار مکان آنها +۴ و +۱۳ و +۱۵ باشد میتوانیم نتیجه بگیریم که دو متحرک ب و پ که فاصلهی بردار آنها ۲ است به هم نزدیکترند تا دو متحرک الف و ب که فاصلهی دو بردار آنها ۱۱ است.
یا اگر از مختصات دو بعدی ایکس و ایگرگ استفاده میکردیم هم کافی بود بردار مبدا متحرک (برداری که طول و عرض آن نشاندهندهی فاصله متحرک از مبدا نسبت به محور افقی و عمودی است) را با بردار جا به جایی آن جمع کنیم تا پیدا کنیم که متحرک در پایان به کجا میرسد. یا برای این که ببینیم از بین سه متحرک الف، ب و پ کدام دو تا به هم نزدیکترند کافی بود که بردارهای آنها را دو به دو از هم کم کنیم و هر کدام که کوچکتر بود را انتخاب کنیم.
بردارسازی که به آن دگرنمایی یا جاسازی (embedding) هم گفته میشود [به معنای جا دادن کلمات در یک فضای چند بعدی یا نمایش کلمات در یک فضای چند بعدی] کمک میکند تا کلمات در یک فضا (مشابه با محورهای مختصات در درس فیزیک) جاسازی شوند. در پایان جاسازی واژگان، هر واژه در نقطهای از این فضا قرار میگیرد که شبیه به نمایش مکان متحرک در مثال قبلی است. هر چه دقت این بردارها بیشتر باشد عملیات بعدی دقیقتر و درستتر خواهد بود.
حالا با در نظر گرفتن آموختههای درس فیزیک بیایید مثالی از بردارهای کلمات را با هم مرور کنیم. برای سادگی فرض میکنیم که دستگاه مختصات یک بعدی است و فقط محور ایکس وجود دارد. در نظر بگیرید که در پایان بردارسازی کلمات، کلمهی «برادر» در نقطهی ۱۱ و کلمهی «مرد» در نقطهی ۶ و کلمهی «زن» در نقطهی +۷ قرار گرفته باشند. حدس بزنید اگر بردارهای «مرد»، «زن» و «برادر» را به شکل زیر جمع و تفریق کنیم نتیجه چه خواهد شد؟
برادر – مرد + زن = ؟
احتمالن درست حدس زدید! نتیجهی این عملیات ریاضی که بردار +۱۲ خواهد بود باید محل قرار گرفتن کلمهی «خواهر» در دستگاه مختصات باشد.
حالا به این پرسش پاسخ دهید:
گیلان – رشت + کردستان = ؟
بله! پاسخ باید برابر با سنندج باشد اگر مکانیزم بردارسازی ما به اندازه کافی دقیق و درست باشد.
با این مقدمه نگاهی بندازیم به ویدیوهای زیر که تلاش دارد نشان دهد چگونه میتوان کلمات را در نقاط مختلف یک فضا جاسازی کرد.
ویدیوی یک: از ابتدا تا دقیقه ۶
https://bit.ly/44Ffth8
ویدیوی دو: از دقیقه ۶:۳۰ تا دقیقه ۱۰:۳۰
https://bit.ly/3ETN10x
https://news.1rj.ru/str/bibalan_com
https://bibalan.com/?p=4780
https://bit.ly/43dytki
در این بخش میخواهیم با هم یاد بگیریم که چگونه یک متن به یک بردار تبدیل میشود. تبدیل متن به بردار یکی از پایهای ترین و مهمترین کارها در پردازش زبان طبیعی و یادگیری ماشین است.
با تبدیل متن به بردار میتوان بخش عمدهای از عملیات مورد نیاز برای پردازش زبان طبیعی به عملیات روی بردارها تبدیل میشود. برای درک این موضوع اجازه دهید مثالی از درس فیزیک را با هم مرور کنیم.
در مبحث حرکت در درس فیزیک، نقطهای را به عنوان مبدا در نظر میگرفتیم. موقعیت متحرک را هم روی محور افقی (محور ایکس) نشان میدادیم. مثلن اگر متحرک در سمت راست مبدا مختصات و به فاصله ۵ متری آن بود آن را به صورت بردار مثبت ۵ (+۵) نشان میدادیم. اگر متحرک به اندازه ۷ متر به سمت چپ حرکت میکرد، میزان جابهجایی آن را به صورت بردار منفی ۷ (-۷) نشان میدادیم. برای پیدا کردن مقصد متحرک کافی است که دو بردار +۵ و -۷ یعنی مبدای حرکت و میزان جا به جایی متحرک را با هم جمع کنیم تا به مقصد یعنی منفی ۲ (-۲) برسیم. در اینجا اگر سه متحرک الف، ب، پ داشته باشیم که بردار مکان آنها +۴ و +۱۳ و +۱۵ باشد میتوانیم نتیجه بگیریم که دو متحرک ب و پ که فاصلهی بردار آنها ۲ است به هم نزدیکترند تا دو متحرک الف و ب که فاصلهی دو بردار آنها ۱۱ است.
یا اگر از مختصات دو بعدی ایکس و ایگرگ استفاده میکردیم هم کافی بود بردار مبدا متحرک (برداری که طول و عرض آن نشاندهندهی فاصله متحرک از مبدا نسبت به محور افقی و عمودی است) را با بردار جا به جایی آن جمع کنیم تا پیدا کنیم که متحرک در پایان به کجا میرسد. یا برای این که ببینیم از بین سه متحرک الف، ب و پ کدام دو تا به هم نزدیکترند کافی بود که بردارهای آنها را دو به دو از هم کم کنیم و هر کدام که کوچکتر بود را انتخاب کنیم.
بردارسازی که به آن دگرنمایی یا جاسازی (embedding) هم گفته میشود [به معنای جا دادن کلمات در یک فضای چند بعدی یا نمایش کلمات در یک فضای چند بعدی] کمک میکند تا کلمات در یک فضا (مشابه با محورهای مختصات در درس فیزیک) جاسازی شوند. در پایان جاسازی واژگان، هر واژه در نقطهای از این فضا قرار میگیرد که شبیه به نمایش مکان متحرک در مثال قبلی است. هر چه دقت این بردارها بیشتر باشد عملیات بعدی دقیقتر و درستتر خواهد بود.
حالا با در نظر گرفتن آموختههای درس فیزیک بیایید مثالی از بردارهای کلمات را با هم مرور کنیم. برای سادگی فرض میکنیم که دستگاه مختصات یک بعدی است و فقط محور ایکس وجود دارد. در نظر بگیرید که در پایان بردارسازی کلمات، کلمهی «برادر» در نقطهی ۱۱ و کلمهی «مرد» در نقطهی ۶ و کلمهی «زن» در نقطهی +۷ قرار گرفته باشند. حدس بزنید اگر بردارهای «مرد»، «زن» و «برادر» را به شکل زیر جمع و تفریق کنیم نتیجه چه خواهد شد؟
برادر – مرد + زن = ؟
احتمالن درست حدس زدید! نتیجهی این عملیات ریاضی که بردار +۱۲ خواهد بود باید محل قرار گرفتن کلمهی «خواهر» در دستگاه مختصات باشد.
حالا به این پرسش پاسخ دهید:
گیلان – رشت + کردستان = ؟
بله! پاسخ باید برابر با سنندج باشد اگر مکانیزم بردارسازی ما به اندازه کافی دقیق و درست باشد.
با این مقدمه نگاهی بندازیم به ویدیوهای زیر که تلاش دارد نشان دهد چگونه میتوان کلمات را در نقاط مختلف یک فضا جاسازی کرد.
ویدیوی یک: از ابتدا تا دقیقه ۶
https://bit.ly/44Ffth8
ویدیوی دو: از دقیقه ۶:۳۰ تا دقیقه ۱۰:۳۰
https://bit.ly/3ETN10x
https://news.1rj.ru/str/bibalan_com
https://bibalan.com/?p=4780
👍5👏2
مدل شما چه ساعتی را نشان میدهد؟
پیشگفتار: فرضیهی پیچیدگی متناسب تورنگیت
(Thorngate’s postulate of commensurate complexity)
فرضیهی پیچیدگی متناسب، توصیفی از یک پدیده در نظریهپردازی علوم اجتماعی است. کارل ای. ویک (Karl E. Weick) ادعا میکند که تحقیقات در زمینه روانشناسی اجتماعی همواره میتواند فقط دو ویژگی از سه ویژگی متا-نظری ‘عمومیت’ (Generality)، ‘دقت’ (Accuracy) و ‘سادگی’ (Simplicity) را داشته باشد. بنابراین، یکی از این سه ویژگی همیشه باید تابع دو ویژگی دیگر باشد.به عبارت سادهتر یک مدل تنها دو ویژگی از سه ویژگی عام بودن، دقیق بودن و ساده بودن را داشته باشد و نه هر سهی آنها را.
این فرضیه به نام روانشناس اجتماعی کانادایی وارن تورنگیت (Warren Thorngate) از دانشگاه آلبرتا نامگذاری شده است. وی در توصیف مساله میگوید: «برای افزایش عمومیت دقت نظریهها به ناچار باید پیچیدگی آنها افزایش یابد».
کارل ویک برای نمایش این مفهوم از تصویر ساعت زیر استفاده کرد. در این ساعت روی ساعت ۱۲، ۴ و ۸ سه عبارت عمومیت، دقت و ساده نوشته شده است. حالا به مفهوم ساعت ۲ و ۶ و ۱۰ دقت کنید
– ساعت ۲: تحقیقات برای همه جا قابل استفادهاند و جزئیات زیادی هم دارند، اما پیچیده میشوند و سادگی خود را از دست میدهند.
– ساعت ۶: تحقیقات برای یک زمینه خاص مفیداند، اما نتایجشان به طور کلی قابل اعمال به دیگر زمینهها و تعمیمپذیر نیستند.
ساعت ۱۰: تحقیقات برای همه جا قابل استفادهاند و به آسانی قابل درکاند، اما جزئیات کافی و خیلی دقیقی ندارند.
https://bit.ly/43qYZXF
کارل ویک ادعا میکند که شما باید یک تصمیم بینابینی (tradeoff) برای انتخاب این سه ویژگی بگیرید زیرا در هر زمان تنها دو تای آنها قابل دستیابی هستند.
گفتار: در دنیای مدل شما، ساعت چند است؟
نکته جالب این است که مدل تورنگیت را میتوان در نرمافزار به کار گرفت. و نکتهی جالبتر این که وقتی با مسالهای رو به رو میشویم و میخواهیم برای آن راه حلی ارایه بدهیم یک چیزهایی از از راه حل (شما بخوانید مدل) را در ذهن خود ترسیم میکنیم.
اجازه دهید یک مثال ساده را با هم حل کنیم. میخواهیم پایگاه دادهی یک سیستم کوچک بانکی که واریز و برداشت دارد را طراحی کنیم. آیا شما دو جدول جدا برای واریز و برداشت در نظر میگیرید یا یک جدول به نام تراکنش که شامل واریز و برداشت است. حالا اگر با عینک ساده بودن-عام بودن-دقیق بودن به راه حل خودتان نگاه کنید روی چه ساعتی قرار گرفتهاید؟
اکنون وقت آن است که چند راه حل قبلی خودتان را مرور کنید و ببینید در دنیای راهکارهای شما ساعت چند است.
منبع:
– ایدهی این نوشته از کتاب Mastering DDD نوشتهی Annegret Junker آمده است.
https://news.1rj.ru/str/bibalan_com
https://bibalan.com/?p=4785
پیشگفتار: فرضیهی پیچیدگی متناسب تورنگیت
(Thorngate’s postulate of commensurate complexity)
فرضیهی پیچیدگی متناسب، توصیفی از یک پدیده در نظریهپردازی علوم اجتماعی است. کارل ای. ویک (Karl E. Weick) ادعا میکند که تحقیقات در زمینه روانشناسی اجتماعی همواره میتواند فقط دو ویژگی از سه ویژگی متا-نظری ‘عمومیت’ (Generality)، ‘دقت’ (Accuracy) و ‘سادگی’ (Simplicity) را داشته باشد. بنابراین، یکی از این سه ویژگی همیشه باید تابع دو ویژگی دیگر باشد.به عبارت سادهتر یک مدل تنها دو ویژگی از سه ویژگی عام بودن، دقیق بودن و ساده بودن را داشته باشد و نه هر سهی آنها را.
این فرضیه به نام روانشناس اجتماعی کانادایی وارن تورنگیت (Warren Thorngate) از دانشگاه آلبرتا نامگذاری شده است. وی در توصیف مساله میگوید: «برای افزایش عمومیت دقت نظریهها به ناچار باید پیچیدگی آنها افزایش یابد».
کارل ویک برای نمایش این مفهوم از تصویر ساعت زیر استفاده کرد. در این ساعت روی ساعت ۱۲، ۴ و ۸ سه عبارت عمومیت، دقت و ساده نوشته شده است. حالا به مفهوم ساعت ۲ و ۶ و ۱۰ دقت کنید
– ساعت ۲: تحقیقات برای همه جا قابل استفادهاند و جزئیات زیادی هم دارند، اما پیچیده میشوند و سادگی خود را از دست میدهند.
– ساعت ۶: تحقیقات برای یک زمینه خاص مفیداند، اما نتایجشان به طور کلی قابل اعمال به دیگر زمینهها و تعمیمپذیر نیستند.
ساعت ۱۰: تحقیقات برای همه جا قابل استفادهاند و به آسانی قابل درکاند، اما جزئیات کافی و خیلی دقیقی ندارند.
https://bit.ly/43qYZXF
کارل ویک ادعا میکند که شما باید یک تصمیم بینابینی (tradeoff) برای انتخاب این سه ویژگی بگیرید زیرا در هر زمان تنها دو تای آنها قابل دستیابی هستند.
گفتار: در دنیای مدل شما، ساعت چند است؟
نکته جالب این است که مدل تورنگیت را میتوان در نرمافزار به کار گرفت. و نکتهی جالبتر این که وقتی با مسالهای رو به رو میشویم و میخواهیم برای آن راه حلی ارایه بدهیم یک چیزهایی از از راه حل (شما بخوانید مدل) را در ذهن خود ترسیم میکنیم.
اجازه دهید یک مثال ساده را با هم حل کنیم. میخواهیم پایگاه دادهی یک سیستم کوچک بانکی که واریز و برداشت دارد را طراحی کنیم. آیا شما دو جدول جدا برای واریز و برداشت در نظر میگیرید یا یک جدول به نام تراکنش که شامل واریز و برداشت است. حالا اگر با عینک ساده بودن-عام بودن-دقیق بودن به راه حل خودتان نگاه کنید روی چه ساعتی قرار گرفتهاید؟
اکنون وقت آن است که چند راه حل قبلی خودتان را مرور کنید و ببینید در دنیای راهکارهای شما ساعت چند است.
منبع:
– ایدهی این نوشته از کتاب Mastering DDD نوشتهی Annegret Junker آمده است.
https://news.1rj.ru/str/bibalan_com
https://bibalan.com/?p=4785
👍9❤4🤔3🤩1
برنامهنویس خوب از نگاه تراویس الفنت
https://bit.ly/46QQtEG
پیش گفتار:
تراویس الفنت (Travis Oliphant) یکی از تاثیرگذارترین برنامهنویسان و دانشمندان داده است. او خالق NumPy و همبنیانگذار SciPy و Anaconda و NumFOCUS است. این نوشته برگرفته از مصاحبهای است که لکس فریدمن (Lex Fridman) با وی انجام داده است.
گفتار:
لکس فریدمن: میخواستم ازت چیزی بپرسم چون تو یکی از تاثیرگذارترین برنامهنویسان تاریخی و رهبر (مدیر) برنامهنویسان زیادی بودی و هنوز هم هستی. از دیدگاه یه برنامهنویس، چه عواملی باعث میشه یه برنامهنویس، برنامهنویس خوبی بشه و یا چی باعث میشه یه برنامه نویس، برنامهنویسی بشه با کارایی بالا.
تراویس الفنت: سوالات سوال خیلی خوبییه. فکر میکنم در دورههایی از زندگیام میتونستم جواب بهتری به این سوال بدم، چون من بارها به این موضوع فکر کردم. الان بیشتر وقتام صرف استخدام همکاران بخش فروش میشه و ذهنم درگیر اونه.
ولی با مرور تجربیات گذشتهام و همچنین کار کردن با برنامهنویسهای واقعن فوقالعادهای که تیمهاشون رو رهبری میکنند و کار من الهامبخشی و اگه بشه کمک و حمایت اونها و تیمهاشونه، میتونم به چند نکتهی کلیدی رو اشاره کنم.
اولی کنجکاوییه(curiosity)! برنامهنویسی که کنجکاو نباشه، یه برنامهنویس معمولی میشه. خیلی زود هم انگیزهاش رو از دست میده. همهی تلاشاش رو هم نمیکنه. کنجکاوی اساسن یه ویژگی شخصییه – یعنی اینکه شما تا چه حد دربارهی موضوعات کنجکاو هستید.
دومی اینه که نباید تلاش کنید همه چیز رو با هم و یهباره انجام بدهد. باید بپذیرید که ما به عنوان انسان محدودیتهایی داریم. هر کدام از ما هم محدودیتهای خاص خودمون رو داریم و هر کدوم هم نقاط قوت و مهارتهای خاص خودمون رو داریم. بنابراین، باید هنر برنامهنویسی رو با مهارتهای خودتون تطبیق دهید.
یکی از چیزهایی که همیشه جواب میده اینه که مسالهای که میخواهید حل کنید رو کوچک و محدود کنید. اگر عضو تیمی هستید احتمالن یکی دیگه معماری پروژه را آماده میکنه و یه بخشی از کار رو به شما میده. اگه جوونید یا عضو تیمی نیستید، برای این که کار رو پیش ببرید خیلی مهمه که مساله رو به بخشهای کوچکتر بشکنید. اگه یه پروژه بزرگ رو بردارید و بخواهید همه چیز را یکجا و یکباره انجام بدید، دور از انتظار نیست که توی اون گم بشید و کار رو به شکل بدی انجام بدید.
بنابراین، باید خیلی دقیق دربارهی کاری که میخواهید انجام بدید فکر کنید. مشخص کردن ورودیها و خروجیها، و تعریف دقیق کاری که باید انجام بشه حتی با روش سادهای مثل نوشتن قبل از شروع کدنویسی خیلی مفیده. این که بدونید چه کار میخواهید بکنید و اون رو دقیق بیان بکنید واقعن مفیده.
از کارهای دیگران هم استفاده بکنید. فکر نکنید که باید همه چیز رو خودتون انجام بدید. هیچکس این کار رو نمیکنه. روی شانههای غولها بایستید (کنایه از اینکه از کارهای بقیه استفاده کنید). اما این جوری نباشه که فقط کپی-پیست بکنید. این موضوع بهویژه در دورهی کنونی که کدکس (Codex – ابزار هوش مصنوعی OpenAI برای تولید کد) و کدهای خودکار تولیدشده اهمیت بیشتری داره. …. نکته اینجاست که کپی-پیست کنید ولی نه کپی-پیست کورکورانه. خودم بارها و بارها کپی-پیست کردهام تا بفهمم و بعد متوجه شدم که این کد چه معنایی داره و چه کاری انجام میده. تا جایی که میتونید باید کد رو بفهمید و درک کنید. توی این شرایط، کنجکاوی خیلی مهمه. اگر فقط کورکورانه کپی-پیست کنید، چیزی یاد نمیگیرید.
نکتهی بعدی اینه که حواستون به چرخههای هیجان (hype cycle) باشه [توضیح پایین رو بخونید]. هر چند وقت یکبار، چیزی میآد که همه میگند «این جواب همهی مشکلاتمونه!». مثلن توسعهی آزمونمحور، برنامهنویسی شیگرا یا چابکی (Agile). مراقب باشید که توی دام این جور چرخههای هیجانی نیفتید. حتمن چیزهای ارزشمندی توی اونها وجود داره که میتونید از اونها یاد بگیرید، اما تقریبن مطمئن باشید که این جور چیزها پاسخ همهی مشکلات نیستند.
توضیح:
چرخهی هیجان (هایپ سایکل) که توسط گارتنر ابداع شده، الگویی است که نشان میدهد چگونه فناوریها یا ایدههای جدید از مراحل هیجان اولیه، انتظارات غیرواقعی، ناامیدی، و سپس پذیرش عملی میگذرند. مثلن وقتی «برنامهنویسی شیگرا» معرفی شد، خیلیها فکر میکردند این روش پاسخ همه مشکلات برنامهنویسی است (اوج هیجان). اما بعد، متوجه شدند که برای هر پروژهای مناسب نیست (ناامیدی). با گذشت زمان، برنامهنویسان یاد گرفتند از آن در جاهایی که واقعاً مفید است استفاده کنند (پذیرش عملی). این یک چرخهی هیجان است که باید با احتیاط به آن نگاه کرد.
گزیده:
ندارد.
https://news.1rj.ru/str/bibalan_com
https://bibalan.com/?p=4802
https://bit.ly/46QQtEG
پیش گفتار:
تراویس الفنت (Travis Oliphant) یکی از تاثیرگذارترین برنامهنویسان و دانشمندان داده است. او خالق NumPy و همبنیانگذار SciPy و Anaconda و NumFOCUS است. این نوشته برگرفته از مصاحبهای است که لکس فریدمن (Lex Fridman) با وی انجام داده است.
گفتار:
لکس فریدمن: میخواستم ازت چیزی بپرسم چون تو یکی از تاثیرگذارترین برنامهنویسان تاریخی و رهبر (مدیر) برنامهنویسان زیادی بودی و هنوز هم هستی. از دیدگاه یه برنامهنویس، چه عواملی باعث میشه یه برنامهنویس، برنامهنویس خوبی بشه و یا چی باعث میشه یه برنامه نویس، برنامهنویسی بشه با کارایی بالا.
تراویس الفنت: سوالات سوال خیلی خوبییه. فکر میکنم در دورههایی از زندگیام میتونستم جواب بهتری به این سوال بدم، چون من بارها به این موضوع فکر کردم. الان بیشتر وقتام صرف استخدام همکاران بخش فروش میشه و ذهنم درگیر اونه.
ولی با مرور تجربیات گذشتهام و همچنین کار کردن با برنامهنویسهای واقعن فوقالعادهای که تیمهاشون رو رهبری میکنند و کار من الهامبخشی و اگه بشه کمک و حمایت اونها و تیمهاشونه، میتونم به چند نکتهی کلیدی رو اشاره کنم.
اولی کنجکاوییه(curiosity)! برنامهنویسی که کنجکاو نباشه، یه برنامهنویس معمولی میشه. خیلی زود هم انگیزهاش رو از دست میده. همهی تلاشاش رو هم نمیکنه. کنجکاوی اساسن یه ویژگی شخصییه – یعنی اینکه شما تا چه حد دربارهی موضوعات کنجکاو هستید.
دومی اینه که نباید تلاش کنید همه چیز رو با هم و یهباره انجام بدهد. باید بپذیرید که ما به عنوان انسان محدودیتهایی داریم. هر کدام از ما هم محدودیتهای خاص خودمون رو داریم و هر کدوم هم نقاط قوت و مهارتهای خاص خودمون رو داریم. بنابراین، باید هنر برنامهنویسی رو با مهارتهای خودتون تطبیق دهید.
یکی از چیزهایی که همیشه جواب میده اینه که مسالهای که میخواهید حل کنید رو کوچک و محدود کنید. اگر عضو تیمی هستید احتمالن یکی دیگه معماری پروژه را آماده میکنه و یه بخشی از کار رو به شما میده. اگه جوونید یا عضو تیمی نیستید، برای این که کار رو پیش ببرید خیلی مهمه که مساله رو به بخشهای کوچکتر بشکنید. اگه یه پروژه بزرگ رو بردارید و بخواهید همه چیز را یکجا و یکباره انجام بدید، دور از انتظار نیست که توی اون گم بشید و کار رو به شکل بدی انجام بدید.
بنابراین، باید خیلی دقیق دربارهی کاری که میخواهید انجام بدید فکر کنید. مشخص کردن ورودیها و خروجیها، و تعریف دقیق کاری که باید انجام بشه حتی با روش سادهای مثل نوشتن قبل از شروع کدنویسی خیلی مفیده. این که بدونید چه کار میخواهید بکنید و اون رو دقیق بیان بکنید واقعن مفیده.
از کارهای دیگران هم استفاده بکنید. فکر نکنید که باید همه چیز رو خودتون انجام بدید. هیچکس این کار رو نمیکنه. روی شانههای غولها بایستید (کنایه از اینکه از کارهای بقیه استفاده کنید). اما این جوری نباشه که فقط کپی-پیست بکنید. این موضوع بهویژه در دورهی کنونی که کدکس (Codex – ابزار هوش مصنوعی OpenAI برای تولید کد) و کدهای خودکار تولیدشده اهمیت بیشتری داره. …. نکته اینجاست که کپی-پیست کنید ولی نه کپی-پیست کورکورانه. خودم بارها و بارها کپی-پیست کردهام تا بفهمم و بعد متوجه شدم که این کد چه معنایی داره و چه کاری انجام میده. تا جایی که میتونید باید کد رو بفهمید و درک کنید. توی این شرایط، کنجکاوی خیلی مهمه. اگر فقط کورکورانه کپی-پیست کنید، چیزی یاد نمیگیرید.
نکتهی بعدی اینه که حواستون به چرخههای هیجان (hype cycle) باشه [توضیح پایین رو بخونید]. هر چند وقت یکبار، چیزی میآد که همه میگند «این جواب همهی مشکلاتمونه!». مثلن توسعهی آزمونمحور، برنامهنویسی شیگرا یا چابکی (Agile). مراقب باشید که توی دام این جور چرخههای هیجانی نیفتید. حتمن چیزهای ارزشمندی توی اونها وجود داره که میتونید از اونها یاد بگیرید، اما تقریبن مطمئن باشید که این جور چیزها پاسخ همهی مشکلات نیستند.
توضیح:
چرخهی هیجان (هایپ سایکل) که توسط گارتنر ابداع شده، الگویی است که نشان میدهد چگونه فناوریها یا ایدههای جدید از مراحل هیجان اولیه، انتظارات غیرواقعی، ناامیدی، و سپس پذیرش عملی میگذرند. مثلن وقتی «برنامهنویسی شیگرا» معرفی شد، خیلیها فکر میکردند این روش پاسخ همه مشکلات برنامهنویسی است (اوج هیجان). اما بعد، متوجه شدند که برای هر پروژهای مناسب نیست (ناامیدی). با گذشت زمان، برنامهنویسان یاد گرفتند از آن در جاهایی که واقعاً مفید است استفاده کنند (پذیرش عملی). این یک چرخهی هیجان است که باید با احتیاط به آن نگاه کرد.
گزیده:
ندارد.
https://news.1rj.ru/str/bibalan_com
https://bibalan.com/?p=4802
👍14❤6🔥1
فراتر از هیاهو: سنجش تأثیر واقعی هوش مصنوعی بر بهرهوری توسعهدهندگان -بخش اول
https://bit.ly/4mmZL00
پیشگفتار
چند باری با یکی از دوستان عزیزم («می مهدی») در مورد تاثیر هوش مصنوعی بر آیندهی توسعهی نرمافزار صحبت کردیم. این گفتگو بهانهای شد تا کمی بیشتر به آن بپردازم. هفتهی گذشته یک سخنرانی بسیار ارزشمند رو به صورت اتفاقی دیدم و بر آن شدم تا خلاصهای از آن را به فارسی برگردانم. امیدوارم برای شما عزیزان مفید باشد.
اصل سخنرانی را میتونید در آدرس زیر پیدا کنید.
https://www.youtube.com/watch?v=tbDDYKRFjhk
اهمیت سخنرانی
دستیارهای کدنویسی هوش مصنوعی (AI Coding Assistants) بهسرعت وارد مهندسی نرمافزار شدهاند، اما تأثیر واقعی آنها همچنان نامشخص است. آیا استفاده از آنها واقعن تحویل نرمافزار را سریعتر میکند یا صرفن باعث میشوند کد بیشتری تولید شود که توسعهدهندگان مجبور میشوند بعدن آن را اصلاح کنند؟ این سوال برای مدیران ارشد فناوری و مدیران مهندسی که مسئول ارزیابی پذیرش هوش مصنوعی هستند، حیاتی است.
یگور دنیسوف-بلانچ (Yegor Denisov-Blanch) در سخنرانی خود در استنفورد، یافتههایی از یکی از بزرگترین مطالعات تجربی درباره بهرهوری توسعهدهندگان ارائه میدهد که بر پایهی دادههای بیش از ۱۰۰,۰۰۰ توسعهدهنده است.
دنیسوف-بلانچ، پژوهشگر استنفورد در حوزه مهندسی نرمافزار دادهمحور (data-driven software engineering)، مطالعهای چندساله را ارائه کرد که بیش از ۶۰۰ شرکت و میلیاردها خط کد را شامل میشود که ۸۰٪ آنها کدهای شرکتها هستند (اهمیت استفاده از کدهای خصوصی (private repositories) به جای کدهای در دسترس عموم ( public repositories) در ارایه توضیح داده شده است).
پژوهش او به این سؤال پاسخ میدهد: هوش مصنوعی تا چه اندازه و تحت چه شرایطی بهرهوری توسعهدهندگان را بهبود میبخشد؟
استدلالهای اصلی
۱. چرا مطالعات سنتی شکست میخورند
بیشتر مطالعات بهرهوری که توسط فروشندگان (vendor) انجام یا هدایت میشوند، بر مبنای معیارهای ناقصی مانند تعداد کامیتها (commit)، تعداد پیآر (PR) یا نظرسنجیها انجام میشوند. اما این معیارها با نادیده گرفتن تفاوتهای اندازه و بزرگی کارها (task size) یا چرخهی رفع اشکال (bug-fix churn)، بهرهوری را بیش از حد نشان میدهند. به گفته دنیسوف-بلانچ: «ارائه کامیتهای بیشتر لزومن به معنای بهرهوری بیشتر نیست.». از سوی دیگر، نظرسنجیهایی که با مشارکت توسعهدهندگان انجام میشوند نیز عملکرد بهتری ندارند و آمار نشان میدهد که «توسعهدهندگان بهرهوری خود را بهطور متوسط ۳۰ درصد اشتباه تخمین میزنند».
پیامد عملی این واقعیتها این است که رهبران و مدیران باید نسبت به ادعاهای بازاریابی هشیار و محتاط باشند و چارچوبهای اندازهگیری قوی و درستی را اتخاذ کنند.
۲. اندازهگیری آنچه اهمیت دارد
تیم استنفورد مدلی طراحی کرده که کارکردهای تحویلی (functionality delivered) را کمیسازی میکند که در آن، نتایج توسط گروهی از مهندسان متخصص بررسی و اعتبارسنجی میشود. این مدل، «خروجی بهدرد بخور و مفید» (useful output) را به جای معیارهایی مانند تعداد خطوط اندازهگیری میکند. در کل، دستیارهای کدنویسی در ظاهر بهرهوری را ۳۰-۴۰٪ را افزایش میدهند (بهرهوری ظاهری)، اما بخش زیادی از این بهرهوری به دلیل «دوبارهکاری» (rework) و رفع اشتباهات هوش مصنوعی خنثی شده و کاهش پیدا میکند. در نتیجه بهرهوری به صورت خالص و پایدار حدود ۱۵-۲۰٪ افزایش مییابد.
پیامد عملی: پذیرش هوش مصنوعی با در نظر گرفتن رفع خطاها، بهرهوری را افزایش میدهد و میزان افزایش، «متوسط» است.
گزیده:
ندارد.
https://news.1rj.ru/str/bibalan_com
https://bibalan.com/?p=4811
https://bit.ly/4mmZL00
پیشگفتار
چند باری با یکی از دوستان عزیزم («می مهدی») در مورد تاثیر هوش مصنوعی بر آیندهی توسعهی نرمافزار صحبت کردیم. این گفتگو بهانهای شد تا کمی بیشتر به آن بپردازم. هفتهی گذشته یک سخنرانی بسیار ارزشمند رو به صورت اتفاقی دیدم و بر آن شدم تا خلاصهای از آن را به فارسی برگردانم. امیدوارم برای شما عزیزان مفید باشد.
اصل سخنرانی را میتونید در آدرس زیر پیدا کنید.
https://www.youtube.com/watch?v=tbDDYKRFjhk
اهمیت سخنرانی
دستیارهای کدنویسی هوش مصنوعی (AI Coding Assistants) بهسرعت وارد مهندسی نرمافزار شدهاند، اما تأثیر واقعی آنها همچنان نامشخص است. آیا استفاده از آنها واقعن تحویل نرمافزار را سریعتر میکند یا صرفن باعث میشوند کد بیشتری تولید شود که توسعهدهندگان مجبور میشوند بعدن آن را اصلاح کنند؟ این سوال برای مدیران ارشد فناوری و مدیران مهندسی که مسئول ارزیابی پذیرش هوش مصنوعی هستند، حیاتی است.
یگور دنیسوف-بلانچ (Yegor Denisov-Blanch) در سخنرانی خود در استنفورد، یافتههایی از یکی از بزرگترین مطالعات تجربی درباره بهرهوری توسعهدهندگان ارائه میدهد که بر پایهی دادههای بیش از ۱۰۰,۰۰۰ توسعهدهنده است.
دنیسوف-بلانچ، پژوهشگر استنفورد در حوزه مهندسی نرمافزار دادهمحور (data-driven software engineering)، مطالعهای چندساله را ارائه کرد که بیش از ۶۰۰ شرکت و میلیاردها خط کد را شامل میشود که ۸۰٪ آنها کدهای شرکتها هستند (اهمیت استفاده از کدهای خصوصی (private repositories) به جای کدهای در دسترس عموم ( public repositories) در ارایه توضیح داده شده است).
پژوهش او به این سؤال پاسخ میدهد: هوش مصنوعی تا چه اندازه و تحت چه شرایطی بهرهوری توسعهدهندگان را بهبود میبخشد؟
استدلالهای اصلی
۱. چرا مطالعات سنتی شکست میخورند
بیشتر مطالعات بهرهوری که توسط فروشندگان (vendor) انجام یا هدایت میشوند، بر مبنای معیارهای ناقصی مانند تعداد کامیتها (commit)، تعداد پیآر (PR) یا نظرسنجیها انجام میشوند. اما این معیارها با نادیده گرفتن تفاوتهای اندازه و بزرگی کارها (task size) یا چرخهی رفع اشکال (bug-fix churn)، بهرهوری را بیش از حد نشان میدهند. به گفته دنیسوف-بلانچ: «ارائه کامیتهای بیشتر لزومن به معنای بهرهوری بیشتر نیست.». از سوی دیگر، نظرسنجیهایی که با مشارکت توسعهدهندگان انجام میشوند نیز عملکرد بهتری ندارند و آمار نشان میدهد که «توسعهدهندگان بهرهوری خود را بهطور متوسط ۳۰ درصد اشتباه تخمین میزنند».
پیامد عملی این واقعیتها این است که رهبران و مدیران باید نسبت به ادعاهای بازاریابی هشیار و محتاط باشند و چارچوبهای اندازهگیری قوی و درستی را اتخاذ کنند.
۲. اندازهگیری آنچه اهمیت دارد
تیم استنفورد مدلی طراحی کرده که کارکردهای تحویلی (functionality delivered) را کمیسازی میکند که در آن، نتایج توسط گروهی از مهندسان متخصص بررسی و اعتبارسنجی میشود. این مدل، «خروجی بهدرد بخور و مفید» (useful output) را به جای معیارهایی مانند تعداد خطوط اندازهگیری میکند. در کل، دستیارهای کدنویسی در ظاهر بهرهوری را ۳۰-۴۰٪ را افزایش میدهند (بهرهوری ظاهری)، اما بخش زیادی از این بهرهوری به دلیل «دوبارهکاری» (rework) و رفع اشتباهات هوش مصنوعی خنثی شده و کاهش پیدا میکند. در نتیجه بهرهوری به صورت خالص و پایدار حدود ۱۵-۲۰٪ افزایش مییابد.
پیامد عملی: پذیرش هوش مصنوعی با در نظر گرفتن رفع خطاها، بهرهوری را افزایش میدهد و میزان افزایش، «متوسط» است.
گزیده:
ندارد.
https://news.1rj.ru/str/bibalan_com
https://bibalan.com/?p=4811
👍5
فراتر از هیاهو: سنجش تأثیر واقعی هوش مصنوعی بر بهرهوری توسعهدهندگان -بخش دوم
https://bit.ly/4mmZL00
۳. بهرهوری بر اساس پیچیدگی وظایف متفاوت است
نتایج از ۱۳۶ تیم در ۲۷ شرکت نشاندهندهی تفاوت آشکاری در نتایج است:
کارها با پیچیدگی کم در پروژهها جدید (greenfield): افزایش ۳۰-۴۰٪
کارها با پیچیدگی زیاد در پروژههای جدید (greenfield): افزایش ۱۰-۱۵٪
کارها با پیچیدگی کم در پروژههای موجود (brownfield): افزایش ۱۵-۲۰٪
کارها با پیچیدگی زیاد در پروژههای موجود (brownfield): افزایش ۰-۱۰٪
یادآوری: گرینفیلد به پروژهای گفته میشود که از صفر شروع میشود و براونفیلد به پروژه یا کد موجود گفته میشود.
این نشان میدهد که نه فقط انتخاب ابزار بلکه که نوع کار نیز در نتایج بهرهوری بسیار تاثیرگذار است.
پیامد عملی: هوش مصنوعی باید برای ایجاد ساختار ابتدایی کد (Scaffolding) (مانند ایجاد فولدرها، فایلها، پیکربندی و کد ابتدایی پروژه)، کدهای تکراری و استاندارد (Boilerplate) (مانند نوشتن مدلهای پایگاه داده یا کدهای CRUD) یا افزودن ویژگیهای ساده بهویژه برای پروژههای جدید، هدفمند و بهینه شود.
۴. زبان اهمیت دارد
هوش مصنوعی در زبانهای معروف و اصلی مانند پایتون، جاوا، جاوااسکریپت و تایپاسکریپت بسیار مؤثر است و باعث افزایش ۱۰-۲۰٪ بهرهوری میشود. در زبانهای کممحبوب مانند هسکل، اکسیر یا کوبول (Haskell, Elixir, COBOL)، هوش مصنوعی نهتنها مزایای زیادی به همراه ندارد، بلکه میتواند با تولید کد بیکیفیت، بهرهوری را کاهش دهد.
پیامد عملی: سرمایهگذاری در هوش مصنوعی باید بر اساس زبان برنامهنویسی انجام شود ؛ سرمایهگذاری روی تکنولوژیها و زبانهای خاص، ناشناخته و کممصرف ممکن است فایدهی چندانی به همراه نداشته باشند.
۵. اندازه پایگاه کد و محدودیتهای زمینه
هر چه پایگاه کد (code base) بزرگتر و قدیمیتر، بازده هوش مصنوعی در آن کمتر است. حتی با پنجرههای زمینهی بزرگ [پنجره زمینه یا context window به تعداد توکن یا کلمهای گفته میشود که یک مدل زبانی یا LLM میتواند دریافت کند] هم دقت کدهای تولیدشده با افزایش اندازه ورودی کاهش مییابد. به عبارت سادهتر، دقت کدنویسی مدلهای زبانی از حدود ۹۰٪ در ۱,۰۰۰ توکن به حدود ۵۰٪ در ۳۲,۰۰۰ توکن افت میکند.
پیامد عملی: هوش مصنوعی بهتر است برای زمینههای (کانتکست) کوچکتر و ماژولار استفاده شود—پروژههای با ساختار مونولیتها(monolith)، کیفیت کدهای خروجی آن را به شدت کاهش میدهند.
جمعبندی نتایج: دادهها چه واقعیتی را نشان میدهند
جذابترین بینش (insight) و یافته در این تحقیق این است که شکافی بین بهرهوری ادراکی و واقعی (perceived and real productivity) وجود دارد:
افزایش بهرهوری از جنبهی ادراکی: توسعهدهندگان به دلیل تولید سریعتر کد احساس سریعتر بودن و افزایش بهرهوری میکنند.
افزایش بهرهوری از جنبهی واقعی: پس از کسر بهرهوری به دلیل دوبارهکاریها، بهرهوری واقعی بهطور متوسط ۱۵-۲۰٪ است.
توجه به این نکته بسیار مهم است زیرا هوش مصنوعی نمودارهای بهرهوری را یکدست و متوازن تغییر نمیدهد:
در حوزههای عادی (روتین) و با پیچیدگی کم باعث افزایش توان (throughput) میشوند.
در حوزههای پیچیده، قدیمی و زبانهای نامحبوب، نقش چشمگیری در افزایش بهرهوری ندارند و گاه باعث کاهش آن میشوند.
افزایش بهرهوری سازمانی به میزان همراستایی هوش مصنوعی با نوع کار بستگی دارد.
این تحقیق تأکید میکند که هوش مصنوعی شتابدهندهای همهگیر و برای همهی شرایط نیست (universal accelerator) بلکه تقویتکنندهی موقعیتی (situational multiplier) است.
گزیده:
ندارد.
https://news.1rj.ru/str/bibalan_com
https://bibalan.com/?p=4811
https://bit.ly/4mmZL00
۳. بهرهوری بر اساس پیچیدگی وظایف متفاوت است
نتایج از ۱۳۶ تیم در ۲۷ شرکت نشاندهندهی تفاوت آشکاری در نتایج است:
کارها با پیچیدگی کم در پروژهها جدید (greenfield): افزایش ۳۰-۴۰٪
کارها با پیچیدگی زیاد در پروژههای جدید (greenfield): افزایش ۱۰-۱۵٪
کارها با پیچیدگی کم در پروژههای موجود (brownfield): افزایش ۱۵-۲۰٪
کارها با پیچیدگی زیاد در پروژههای موجود (brownfield): افزایش ۰-۱۰٪
یادآوری: گرینفیلد به پروژهای گفته میشود که از صفر شروع میشود و براونفیلد به پروژه یا کد موجود گفته میشود.
این نشان میدهد که نه فقط انتخاب ابزار بلکه که نوع کار نیز در نتایج بهرهوری بسیار تاثیرگذار است.
پیامد عملی: هوش مصنوعی باید برای ایجاد ساختار ابتدایی کد (Scaffolding) (مانند ایجاد فولدرها، فایلها، پیکربندی و کد ابتدایی پروژه)، کدهای تکراری و استاندارد (Boilerplate) (مانند نوشتن مدلهای پایگاه داده یا کدهای CRUD) یا افزودن ویژگیهای ساده بهویژه برای پروژههای جدید، هدفمند و بهینه شود.
۴. زبان اهمیت دارد
هوش مصنوعی در زبانهای معروف و اصلی مانند پایتون، جاوا، جاوااسکریپت و تایپاسکریپت بسیار مؤثر است و باعث افزایش ۱۰-۲۰٪ بهرهوری میشود. در زبانهای کممحبوب مانند هسکل، اکسیر یا کوبول (Haskell, Elixir, COBOL)، هوش مصنوعی نهتنها مزایای زیادی به همراه ندارد، بلکه میتواند با تولید کد بیکیفیت، بهرهوری را کاهش دهد.
پیامد عملی: سرمایهگذاری در هوش مصنوعی باید بر اساس زبان برنامهنویسی انجام شود ؛ سرمایهگذاری روی تکنولوژیها و زبانهای خاص، ناشناخته و کممصرف ممکن است فایدهی چندانی به همراه نداشته باشند.
۵. اندازه پایگاه کد و محدودیتهای زمینه
هر چه پایگاه کد (code base) بزرگتر و قدیمیتر، بازده هوش مصنوعی در آن کمتر است. حتی با پنجرههای زمینهی بزرگ [پنجره زمینه یا context window به تعداد توکن یا کلمهای گفته میشود که یک مدل زبانی یا LLM میتواند دریافت کند] هم دقت کدهای تولیدشده با افزایش اندازه ورودی کاهش مییابد. به عبارت سادهتر، دقت کدنویسی مدلهای زبانی از حدود ۹۰٪ در ۱,۰۰۰ توکن به حدود ۵۰٪ در ۳۲,۰۰۰ توکن افت میکند.
پیامد عملی: هوش مصنوعی بهتر است برای زمینههای (کانتکست) کوچکتر و ماژولار استفاده شود—پروژههای با ساختار مونولیتها(monolith)، کیفیت کدهای خروجی آن را به شدت کاهش میدهند.
جمعبندی نتایج: دادهها چه واقعیتی را نشان میدهند
جذابترین بینش (insight) و یافته در این تحقیق این است که شکافی بین بهرهوری ادراکی و واقعی (perceived and real productivity) وجود دارد:
افزایش بهرهوری از جنبهی ادراکی: توسعهدهندگان به دلیل تولید سریعتر کد احساس سریعتر بودن و افزایش بهرهوری میکنند.
افزایش بهرهوری از جنبهی واقعی: پس از کسر بهرهوری به دلیل دوبارهکاریها، بهرهوری واقعی بهطور متوسط ۱۵-۲۰٪ است.
توجه به این نکته بسیار مهم است زیرا هوش مصنوعی نمودارهای بهرهوری را یکدست و متوازن تغییر نمیدهد:
در حوزههای عادی (روتین) و با پیچیدگی کم باعث افزایش توان (throughput) میشوند.
در حوزههای پیچیده، قدیمی و زبانهای نامحبوب، نقش چشمگیری در افزایش بهرهوری ندارند و گاه باعث کاهش آن میشوند.
افزایش بهرهوری سازمانی به میزان همراستایی هوش مصنوعی با نوع کار بستگی دارد.
این تحقیق تأکید میکند که هوش مصنوعی شتابدهندهای همهگیر و برای همهی شرایط نیست (universal accelerator) بلکه تقویتکنندهی موقعیتی (situational multiplier) است.
گزیده:
ندارد.
https://news.1rj.ru/str/bibalan_com
https://bibalan.com/?p=4811
👍3❤1
فراتر از هیاهو: سنجش تأثیر واقعی هوش مصنوعی بر بهرهوری توسعهدهندگان -بخش سوم
https://bit.ly/4mmZL00
راهنمای پیادهسازی
رهبران مهندسی میتوانند با موارد زیر تأثیر را به حداکثر برسانند:
تطبیق هوش مصنوعی با نوع کار: برای کارهای با پیچیدگی کم استفاده کنید، نه سیستمهای حیاتی.
اندازهگیری کارکردها، نه کامیتها: برای بهرهوری، معیارهای مبتنی بر خروجی و نتایج را اتخاذ کنید.
اولویتبندی زبانهای محبوب: روی پایتون، جاوا، جاوااسکریپت/تایپاسکریپت قبل از تکنولوژیهای خاص تمرکز کنید.
نظارت بر میزان دوبارهکاری: چرخهی رفع اشکال (باگها) را کنترل کنید تا اسیر ادعاهای اغراقآمیز نشوید.
استفاده ماژولار: استفاده از هوش مصنوعی را به زیرسیستمها محدود کنید، نه کل پایگاه کد و مونولیتها.
آموزش توسعهدهندگان: انتظارات را همراستا و مبتنی بر واقعیتها کنید—هوش مصنوعی ابزار است، نه جایگزین.
پذیرش و استفادهی تدریجی و تکراری: معیارهای بهرهوری را هر سه ماه بازبینی کنید، زیرا مدلها در حال تکامل هستند.
ریسکها و محدودیتها
استفاده از دستیارهای کدنویسی هوش مصنوعی در محیطهای قدیمی، پیچیده یا خاص با خطر کاهش بهرهوری همراه است. آنها ممکن است باعث پفکردن کد (تولید کد اضافی)، معرفی اشکالات ظریف و مبهم، و کاهش عمق مهارت توسعهدهندگان (developer skill depth.) شوند. ریسکهای سازمانی شامل انتظارات اغراقآمیز (مثلاً «جایگزینی مهندسان با هوش مصنوعی») و نگرانیهای حریم خصوصی به دلیل پایش و نظارت بر خروجی توسعهدهندگان است.
نتیجهگیری
ابزارهای کدنویسی هوش مصنوعی بهرهوری را افزایش میدهند—اما نه همهجا و نه بهطور یکسان برای همهی موارد. افزایش بهرهوری در کارهای با پیچیدگی کم و پروژههای جدید (گرینفیلد) در زبانهای اصلی بالاتر است و بهطور متوسط ۱۵-۲۰٪ است. مدیران باید رویکردی گزینشی و دادهمحور اتخاذ کنند و هوش مصنوعی را با تکنیکهای مهندسی همراه کنند. در ۶ تا ۱۲ ماه آینده، پیشرفت در افزایش بزرگی زمینه (کانتسک) در مدلهای زبانی ممکن است عملکرد آنها را بهبود بخشد، اما پیچیدگی، اندازه پایگاه کد و دوبارهکاری همچنان محدودیتهای اساسی خواهند بود.
خلاصه
ابزارهای کدنویسی هوش مصنوعی پس از کسر دوبارهکاریها، بهرهوری را ۱۵-۲۰٪ افزایش میدهند.
بهترین نتایج برابر است با افزایش ۳۰-۴۰٪ در بهرهوری برای کارهای با پیچیدگی کم و پروژههای جدید (گرینفیلد) در زبانهای محبوب.
ریسکهای استفاده از آنها عبارتند از بیتأثیری یا تاثیر منفی آنها در محیطهای پیچیده، قدیمی یا با تکنولوژیهای خاص.
گزیده:
ندارد.
https://news.1rj.ru/str/bibalan_com
https://bibalan.com/?p=4811
https://bit.ly/4mmZL00
راهنمای پیادهسازی
رهبران مهندسی میتوانند با موارد زیر تأثیر را به حداکثر برسانند:
تطبیق هوش مصنوعی با نوع کار: برای کارهای با پیچیدگی کم استفاده کنید، نه سیستمهای حیاتی.
اندازهگیری کارکردها، نه کامیتها: برای بهرهوری، معیارهای مبتنی بر خروجی و نتایج را اتخاذ کنید.
اولویتبندی زبانهای محبوب: روی پایتون، جاوا، جاوااسکریپت/تایپاسکریپت قبل از تکنولوژیهای خاص تمرکز کنید.
نظارت بر میزان دوبارهکاری: چرخهی رفع اشکال (باگها) را کنترل کنید تا اسیر ادعاهای اغراقآمیز نشوید.
استفاده ماژولار: استفاده از هوش مصنوعی را به زیرسیستمها محدود کنید، نه کل پایگاه کد و مونولیتها.
آموزش توسعهدهندگان: انتظارات را همراستا و مبتنی بر واقعیتها کنید—هوش مصنوعی ابزار است، نه جایگزین.
پذیرش و استفادهی تدریجی و تکراری: معیارهای بهرهوری را هر سه ماه بازبینی کنید، زیرا مدلها در حال تکامل هستند.
ریسکها و محدودیتها
استفاده از دستیارهای کدنویسی هوش مصنوعی در محیطهای قدیمی، پیچیده یا خاص با خطر کاهش بهرهوری همراه است. آنها ممکن است باعث پفکردن کد (تولید کد اضافی)، معرفی اشکالات ظریف و مبهم، و کاهش عمق مهارت توسعهدهندگان (developer skill depth.) شوند. ریسکهای سازمانی شامل انتظارات اغراقآمیز (مثلاً «جایگزینی مهندسان با هوش مصنوعی») و نگرانیهای حریم خصوصی به دلیل پایش و نظارت بر خروجی توسعهدهندگان است.
نتیجهگیری
ابزارهای کدنویسی هوش مصنوعی بهرهوری را افزایش میدهند—اما نه همهجا و نه بهطور یکسان برای همهی موارد. افزایش بهرهوری در کارهای با پیچیدگی کم و پروژههای جدید (گرینفیلد) در زبانهای اصلی بالاتر است و بهطور متوسط ۱۵-۲۰٪ است. مدیران باید رویکردی گزینشی و دادهمحور اتخاذ کنند و هوش مصنوعی را با تکنیکهای مهندسی همراه کنند. در ۶ تا ۱۲ ماه آینده، پیشرفت در افزایش بزرگی زمینه (کانتسک) در مدلهای زبانی ممکن است عملکرد آنها را بهبود بخشد، اما پیچیدگی، اندازه پایگاه کد و دوبارهکاری همچنان محدودیتهای اساسی خواهند بود.
خلاصه
ابزارهای کدنویسی هوش مصنوعی پس از کسر دوبارهکاریها، بهرهوری را ۱۵-۲۰٪ افزایش میدهند.
بهترین نتایج برابر است با افزایش ۳۰-۴۰٪ در بهرهوری برای کارهای با پیچیدگی کم و پروژههای جدید (گرینفیلد) در زبانهای محبوب.
ریسکهای استفاده از آنها عبارتند از بیتأثیری یا تاثیر منفی آنها در محیطهای پیچیده، قدیمی یا با تکنولوژیهای خاص.
گزیده:
ندارد.
https://news.1rj.ru/str/bibalan_com
https://bibalan.com/?p=4811
👍8
https://bit.ly/3K85RDv
مدل گوشیتون چیه؟
پیشگفتار:
دوستی دارم که رشتهی هنر خونده و علاوه بر دانش عکاسی، تجربهی زیادی هم در این زمینه داره. یک بار برام تعریف میکرد که با گروهی که چندتاشون اون رو نمیشناختند جایی بودند و ازش خواستند که ازشون عکس بگیره. میگفت بعد از این که عکس گرفتم به رسم معمول، عکسها رو نشون همه دادم که ببینند توی عکس خوب افتادند یا نه. بعد از این که از کیفیت عکس و … تعریف کردند یکی از افرادی که با هم آشنایی نداشتیم برگشت گفت «مدل گوشیتون چیه؟»
دوست من با خنده ادامه داد که معمولن در پاسخ به این سوال اول مدل گوشی رو میگم و بعد یک هم از امکانات گوشی برای عکاسی رو توضیح میدم بهشون. اون ادامه داد که چیزی که اون دوستان تازهآشنای من نمیبینند اینه که من سالها عکاسی کردم و درس عکاسی خوندم و اگه عکس خوب شده گوشی فقط یک بخشی از این موفقیت بوده نه همهش! بعد میخنده و میگه: احتمالن این ویژگی همهی آدماست چون خود من هم خیلی اوقات همین برداشت رو از کار بقیه دارم.
گفتار:
رشد سریع و باورنکردنی دستیارهای برنامهنویسی و ابزارهای تولید کد مبتی بر هوش مصنوعی باعث شده که خیلی از کارهای برنامهنویسی فقط با یادگیری «چگونه با ایآی حرف بزنیم» قابل انجام باشه. در نتیجه هر برنامهنویسی که بتونه «بهتر» «زبان دستیارش» رو یاد بگیره احتمالن میتونه کارها رو زودتر و بهتر انجام بده.
برای نمونه ممکنه شما کدی داشته باشید که خیلی «تر و تمیز» نیست، اگه بخواهید خودتون تر و تمیزش کنید باید کلی کتاب بخونید و تجربه داشته باشید تا بدونید «کد تر و تمیز» چه شکلیه و بعد یاد بگیرید «چه جوری کد تر و تمیز بنویسید». اما با وجود یه دستیار هوشمند میتونید کدی ناتمیز رو ظرف مدت کوتاهی تر و تمیز کنید.
نکتهی مهم اینجاست که «کسی که در نهایت باید زیر کد رو امضاء کنه و مسئولیتاش رو بپذیره» شمایید. شما نمیتونید بدون دونستن اینکه کد تر و تمیز چه شکلیه، زیر کدی که دستیارتون تولید کرده رو امضاء کنید. شما اگه ندونید که کد ناتمیز قبلی اگه تبدیل به کد تمیز بشه این شکلی باید بشه، نمیتونید زیر کد تولید شده یا تغییر داده شد رو امضاء کنید.
خلاصه اینکه، درسته که دستیارتون خیلی کارها بلده انجام بده ولی کسی که باید زیر کارهاش رو امضاء کنه شمایید.
این تغییرات سریع و بنیادی ابزارهای هوشمند به قدری «غیرعادیها» را به «عادی» تبدیل کرده که تا چند وقت دیگه اگه یه نفر بیاد و یک کد تر و تمیز رو به شما نشون بده احتمالن ازش میپرسید که «مدل دستیار هوشمندتون چی هست؟». بدون این که ازش بپرسید که شما علاوه بر دستیار، چه چیزهایی خوندید یا تجربه کردید.
گزیده:
شما عکس نمیگیرید، شما اون رو خلق میکنید. انسل آدامز
https://news.1rj.ru/str/bibalan_com
https://bibalan.com/?p=4848
مدل گوشیتون چیه؟
پیشگفتار:
دوستی دارم که رشتهی هنر خونده و علاوه بر دانش عکاسی، تجربهی زیادی هم در این زمینه داره. یک بار برام تعریف میکرد که با گروهی که چندتاشون اون رو نمیشناختند جایی بودند و ازش خواستند که ازشون عکس بگیره. میگفت بعد از این که عکس گرفتم به رسم معمول، عکسها رو نشون همه دادم که ببینند توی عکس خوب افتادند یا نه. بعد از این که از کیفیت عکس و … تعریف کردند یکی از افرادی که با هم آشنایی نداشتیم برگشت گفت «مدل گوشیتون چیه؟»
دوست من با خنده ادامه داد که معمولن در پاسخ به این سوال اول مدل گوشی رو میگم و بعد یک هم از امکانات گوشی برای عکاسی رو توضیح میدم بهشون. اون ادامه داد که چیزی که اون دوستان تازهآشنای من نمیبینند اینه که من سالها عکاسی کردم و درس عکاسی خوندم و اگه عکس خوب شده گوشی فقط یک بخشی از این موفقیت بوده نه همهش! بعد میخنده و میگه: احتمالن این ویژگی همهی آدماست چون خود من هم خیلی اوقات همین برداشت رو از کار بقیه دارم.
گفتار:
رشد سریع و باورنکردنی دستیارهای برنامهنویسی و ابزارهای تولید کد مبتی بر هوش مصنوعی باعث شده که خیلی از کارهای برنامهنویسی فقط با یادگیری «چگونه با ایآی حرف بزنیم» قابل انجام باشه. در نتیجه هر برنامهنویسی که بتونه «بهتر» «زبان دستیارش» رو یاد بگیره احتمالن میتونه کارها رو زودتر و بهتر انجام بده.
برای نمونه ممکنه شما کدی داشته باشید که خیلی «تر و تمیز» نیست، اگه بخواهید خودتون تر و تمیزش کنید باید کلی کتاب بخونید و تجربه داشته باشید تا بدونید «کد تر و تمیز» چه شکلیه و بعد یاد بگیرید «چه جوری کد تر و تمیز بنویسید». اما با وجود یه دستیار هوشمند میتونید کدی ناتمیز رو ظرف مدت کوتاهی تر و تمیز کنید.
نکتهی مهم اینجاست که «کسی که در نهایت باید زیر کد رو امضاء کنه و مسئولیتاش رو بپذیره» شمایید. شما نمیتونید بدون دونستن اینکه کد تر و تمیز چه شکلیه، زیر کدی که دستیارتون تولید کرده رو امضاء کنید. شما اگه ندونید که کد ناتمیز قبلی اگه تبدیل به کد تمیز بشه این شکلی باید بشه، نمیتونید زیر کد تولید شده یا تغییر داده شد رو امضاء کنید.
خلاصه اینکه، درسته که دستیارتون خیلی کارها بلده انجام بده ولی کسی که باید زیر کارهاش رو امضاء کنه شمایید.
این تغییرات سریع و بنیادی ابزارهای هوشمند به قدری «غیرعادیها» را به «عادی» تبدیل کرده که تا چند وقت دیگه اگه یه نفر بیاد و یک کد تر و تمیز رو به شما نشون بده احتمالن ازش میپرسید که «مدل دستیار هوشمندتون چی هست؟». بدون این که ازش بپرسید که شما علاوه بر دستیار، چه چیزهایی خوندید یا تجربه کردید.
گزیده:
شما عکس نمیگیرید، شما اون رو خلق میکنید. انسل آدامز
https://news.1rj.ru/str/bibalan_com
https://bibalan.com/?p=4848
👏16👍8
آدم خوبی باشید!
https://bit.ly/3Kctef8
پیشگفتار:
در دنیای توسعهی نرمافزار، کدنویسی تنها بخشی از ماجراست. جنبه انسانی ماجرا، نه کمتر که شاید بیشتر از جنبهی فنی ماجرا در موفقیت پروژه تاثیرگذاره. جنبهی انسانی توسعهی نرمافزار، اونجا که از «کنار هم کد زدن» به «دیدنهای گاه به گاه از راه دور و از پشت نمایشگر» و بعد به «همتیمیهای ندیده» تبدیل میشه به مراتب سختتر و پیچیدهتر میشه.
چند وقت پیش راهنمایی رو در وبسایت پروژهی SQLModel دیدم که بسیار آموزنده بود. رهبر این پروژه، سباستین رامیرز (معروف به @tiangolo) خالق FastAPI یکی از فریمورکهای معروفِ توسعهی وب توی پایتونه. بخشی از این راهنما رو که خود رامیرز برای برای مدیریت کارها در مخرن کدها (Repository Management Tasks) نوشته در ادامه آوردم. هدفِ بخش غیرفنی این راهنما، نه تنها ترویج رفتار حرفهای، بلکه ایجاد یک فرهنگ پایدار در جامعهی توسعهدهندگان نرمافزاره؛ فرهنگی که حتی در لحظات پرچالش و دعواهای فنی، اولویت با احترام به افراد و قدردانی از تلاشهای آنهاست.
----------------------------------------------
گفتار: آدم خوبی باشید!
مهمتر از همه چیز اینه که آدم خوبی باشید. 😊
اگه شما رو به تیم اضافه کردند معنیاش اینه که شما احتمالن آدم فوقالعاده خوبی هستید، اما میارزه که دوباره اون رو یادآوری کنیم .🤓
برای وقتی که شرایط سخت میشه!
وقتی شرایط خوبه، کارها آسونتره و نیازی هم به دستورالعملهای زیاد و طولانی نیست. اما برای وقتی که شرایط دشواره یکسری راهنما هست که در ادامه میآرم.
سعی کنید جنبهی مثبت ماجرا رو ببینید. به طور کلی، اگه افراد رفتار غیردوستانهای ندارند، سعی کنید از تلاش و علاقهشان تشکر کنید، حتا اگه باهاشون در مورد اون موضوع (بحث فنی یا پیآر) موافق نیستید، ازشون به خاطر علاقهمندیشون به پروژه یا وقتی که گذاشتن تا یه کاری توی پروژه انجام بدند تشکر کنید.
بیان احساسات توی متن کار سختییه، از ایموجیها برای بیان احساساتتون استفاده کنید. 😅
در بحثهای فنی و پیآرها، خیلی اوقات افراد ناراحتیشون رو مستقیم و بدون فیلتر بیان میکنند، خیلی وقتها غلو میکنند، شاکی میشند، طلبکارند و از این جور کارها. این کارها واقعن درست نیستند و وقتی کسی این کارها رو میکنه باعث میشه اولویت ما برای حل مشکلاش بیاد پایین. با اینحال سعی کنید اول نفس عمیقی بکشید و بعد جوابهای آرام و مودبانهای به طرف بدید.
سعی کنید طعنه و کنایه نزنید و نظرات پرخاشگرانهی منفعل ندید[۱]. اگر چیزی نادرسته، به جای کنایه زدن، بهتره (با حفظ آرامش و ادب) حرفتون رو مستقیم و بیپرده بگید[۲].
تلاش کنید تا جای ممکن دقیق و بر اساس واقعیتها صحبت کنید و کلیگویی نکنید.
برای بحثهایی که سختتره مثلن رد کردن یه پیآر، میتونید از من بخواید که اون رو خودم مدیریت کنم.
----------------------------------------------
پانوشت:
۱- پرخاشگری منفعل (Passive-aggressive behavior) نوعی درشتی کردن فردی به فرد دیگر بهصورت غیرمستقیم است. پرخاشگری منفعل بیان غیرمستقیم خصومت است مثلاً به شکل تعلل، طعنه، یکدندگی، ترشرویی، یا انجام ندادن عمدی و چندبارهٔ وظایفی که به شخص محول شده است [ویکیپدیا]. چند نمونه:
* «باشه، هر جور تو بگی …» (با وجود عدم رضایت)
* «اشکالی نداره، مثل همیشه خودم انجاماش میدم.»
* «فکر میکردم این رو میدونی» (باید بدونی ولی نمیدونی)
۲- طعنه (طعنهی تلخ به انگلیسی – bitter sarcasm) به معنای سخنی تلخ، با بیانی برنده، و تمسخر و دست انداختنی است که معمولاً با ریشخند هزل یا دست کم گرفتن بیان میشود [ویکیپدیا]. چند نمونه:
* «به به، باز گل کاشتی! چه میکنه این بازیکن!»
* «چه عجب! بالاخره افتخار دادید تشریف آوردید! آفتاب از کدوم طرف در اومده!»
* «دستات درد نکنه این کار رو داری میدی به من! بیکار بودم حوصلهام سر رفته بود»
—–
آدرس راهنمای اسکیو-ال-مدل:
https://sqlmodel.tiangolo.com/management-tasks/#when-things-are-difficult
تصویر:
جمینای
گزیده:
ندارد!
https://news.1rj.ru/str/bibalan_com
https://bibalan.com/?p=4844
https://bit.ly/3Kctef8
پیشگفتار:
در دنیای توسعهی نرمافزار، کدنویسی تنها بخشی از ماجراست. جنبه انسانی ماجرا، نه کمتر که شاید بیشتر از جنبهی فنی ماجرا در موفقیت پروژه تاثیرگذاره. جنبهی انسانی توسعهی نرمافزار، اونجا که از «کنار هم کد زدن» به «دیدنهای گاه به گاه از راه دور و از پشت نمایشگر» و بعد به «همتیمیهای ندیده» تبدیل میشه به مراتب سختتر و پیچیدهتر میشه.
چند وقت پیش راهنمایی رو در وبسایت پروژهی SQLModel دیدم که بسیار آموزنده بود. رهبر این پروژه، سباستین رامیرز (معروف به @tiangolo) خالق FastAPI یکی از فریمورکهای معروفِ توسعهی وب توی پایتونه. بخشی از این راهنما رو که خود رامیرز برای برای مدیریت کارها در مخرن کدها (Repository Management Tasks) نوشته در ادامه آوردم. هدفِ بخش غیرفنی این راهنما، نه تنها ترویج رفتار حرفهای، بلکه ایجاد یک فرهنگ پایدار در جامعهی توسعهدهندگان نرمافزاره؛ فرهنگی که حتی در لحظات پرچالش و دعواهای فنی، اولویت با احترام به افراد و قدردانی از تلاشهای آنهاست.
----------------------------------------------
گفتار: آدم خوبی باشید!
مهمتر از همه چیز اینه که آدم خوبی باشید. 😊
اگه شما رو به تیم اضافه کردند معنیاش اینه که شما احتمالن آدم فوقالعاده خوبی هستید، اما میارزه که دوباره اون رو یادآوری کنیم .🤓
برای وقتی که شرایط سخت میشه!
وقتی شرایط خوبه، کارها آسونتره و نیازی هم به دستورالعملهای زیاد و طولانی نیست. اما برای وقتی که شرایط دشواره یکسری راهنما هست که در ادامه میآرم.
سعی کنید جنبهی مثبت ماجرا رو ببینید. به طور کلی، اگه افراد رفتار غیردوستانهای ندارند، سعی کنید از تلاش و علاقهشان تشکر کنید، حتا اگه باهاشون در مورد اون موضوع (بحث فنی یا پیآر) موافق نیستید، ازشون به خاطر علاقهمندیشون به پروژه یا وقتی که گذاشتن تا یه کاری توی پروژه انجام بدند تشکر کنید.
بیان احساسات توی متن کار سختییه، از ایموجیها برای بیان احساساتتون استفاده کنید. 😅
در بحثهای فنی و پیآرها، خیلی اوقات افراد ناراحتیشون رو مستقیم و بدون فیلتر بیان میکنند، خیلی وقتها غلو میکنند، شاکی میشند، طلبکارند و از این جور کارها. این کارها واقعن درست نیستند و وقتی کسی این کارها رو میکنه باعث میشه اولویت ما برای حل مشکلاش بیاد پایین. با اینحال سعی کنید اول نفس عمیقی بکشید و بعد جوابهای آرام و مودبانهای به طرف بدید.
سعی کنید طعنه و کنایه نزنید و نظرات پرخاشگرانهی منفعل ندید[۱]. اگر چیزی نادرسته، به جای کنایه زدن، بهتره (با حفظ آرامش و ادب) حرفتون رو مستقیم و بیپرده بگید[۲].
تلاش کنید تا جای ممکن دقیق و بر اساس واقعیتها صحبت کنید و کلیگویی نکنید.
برای بحثهایی که سختتره مثلن رد کردن یه پیآر، میتونید از من بخواید که اون رو خودم مدیریت کنم.
----------------------------------------------
پانوشت:
۱- پرخاشگری منفعل (Passive-aggressive behavior) نوعی درشتی کردن فردی به فرد دیگر بهصورت غیرمستقیم است. پرخاشگری منفعل بیان غیرمستقیم خصومت است مثلاً به شکل تعلل، طعنه، یکدندگی، ترشرویی، یا انجام ندادن عمدی و چندبارهٔ وظایفی که به شخص محول شده است [ویکیپدیا]. چند نمونه:
* «باشه، هر جور تو بگی …» (با وجود عدم رضایت)
* «اشکالی نداره، مثل همیشه خودم انجاماش میدم.»
* «فکر میکردم این رو میدونی» (باید بدونی ولی نمیدونی)
۲- طعنه (طعنهی تلخ به انگلیسی – bitter sarcasm) به معنای سخنی تلخ، با بیانی برنده، و تمسخر و دست انداختنی است که معمولاً با ریشخند هزل یا دست کم گرفتن بیان میشود [ویکیپدیا]. چند نمونه:
* «به به، باز گل کاشتی! چه میکنه این بازیکن!»
* «چه عجب! بالاخره افتخار دادید تشریف آوردید! آفتاب از کدوم طرف در اومده!»
* «دستات درد نکنه این کار رو داری میدی به من! بیکار بودم حوصلهام سر رفته بود»
—–
آدرس راهنمای اسکیو-ال-مدل:
https://sqlmodel.tiangolo.com/management-tasks/#when-things-are-difficult
تصویر:
جمینای
گزیده:
ندارد!
https://news.1rj.ru/str/bibalan_com
https://bibalan.com/?p=4844
👍9👏4❤1
هوش مصنوعی چگونه مهندسی نرمافزار را دگرگون خواهد کرد – با مارتین فاولر
هوش مصنوعی صرفاً یک ابزار جدید نیست؛ بلکه انقلابی در بنیادهای مهندسی نرمافزار است. مارتین فاولر، یکی از تأثیرگذارترین چهرهها در حوزهی اَجایل و معماری نرمافزار، معتقد است که ورود AI بزرگترین دگرگونی در این صنعت از زمان گذار از زبان اسمبلی به زبانهای سطح بالا است.
توصیه میکنم حتمن این ویدیوی ارزشمند را که لینک آن در ادامه آوردهام ببینید.
https://www.youtube.com/watch?v=CQmI4XKTa0U
گزیده:
ندارد!
https://news.1rj.ru/str/bibalan_com
https://bibalan.com/?p=48470
هوش مصنوعی صرفاً یک ابزار جدید نیست؛ بلکه انقلابی در بنیادهای مهندسی نرمافزار است. مارتین فاولر، یکی از تأثیرگذارترین چهرهها در حوزهی اَجایل و معماری نرمافزار، معتقد است که ورود AI بزرگترین دگرگونی در این صنعت از زمان گذار از زبان اسمبلی به زبانهای سطح بالا است.
توصیه میکنم حتمن این ویدیوی ارزشمند را که لینک آن در ادامه آوردهام ببینید.
https://www.youtube.com/watch?v=CQmI4XKTa0U
گزیده:
ندارد!
https://news.1rj.ru/str/bibalan_com
https://bibalan.com/?p=48470
YouTube
How AI will change software engineering – with Martin Fowler
Martin Fowler is one of the most influential people within software architecture, and the broader tech industry. He is the Chief Scientist at Thoughtworks and the author of Refactoring and Patterns of Enterprise Application Architecture, and several other…
❤5👍5👏1
مهندسِ ۱۰ برابر (۱۰x Engineer)
https://bit.ly/3KvxVkp
پیشگفتار:
سیاهی لشکر نیاید به کار
یکی مرد جنگی به از صد هزار
اندرو اِنگ (Andrew Ng)، بنیانگذار DeepLearning.AI و یکی از بنیانگذاران Google Brain، پیام روشن و در عین حال چالشبرانگیزی برای توسعهدهندگان نرمافزار که نظارهگر دنیای هوش مصنوعیاند دارد:
“هوش مصنوعی جایگزین توسعهدهندگان نرمافزار نخواهد شد، اما توسعهدهندگان نرمافزاری که از هوش مصنوعی استفاده میکنند، جایگزین کسانی خواهند شد که استفاده نمیکنند. آینده کدنویسی، سمفونی بین حل مسئله توسط انسان و ظرفیت هوش مصنوعی برای اجرای سریع آنهاست. ارزش اصلی شما از نوشتن کد به معماری، اشکالزدایی و مهمتر از همه، هدایت دستیارهای هوشمند تغییر میکند. یاد بگیرید که به زبان هوش مصنوعی صحبت کنید تا به یک مهندس ۱۰-برابر قویتر تبدیل شوید.”
این بخشهایی است از سخنرانی اندرو انگ با عنوان «از کدنویسی تا محصول در چند ساعت — واقعیت جدید توسعهی مبتنی بر هوش مصنوعی» که برخی از نکات مهم آن را در زیر آوردهام.
گفتار: نکات کلیدی اندرو اِنگ برای توسعهدهندگان:
اِنگ در این گفتگو، مهارتهای عملی، تغییرات فلسفی و گلوگاههای نوظهوری را که توسعهدهندگان باید برای ماندن در خط مقدم بدانند، توضیح میدهد. متن زیر برداشتی است آزاد از صحبتهای ایشان.
۱) تمرکز و نگاهی نو بر سرعت
سرعت، بزرگترین پیشبینیکننده (predictor) موفقیت برای پروژههای نوآورانه است. هوش مصنوعی عامل افزایش این سرعت است: سرعت ساخت نمونههای اولیه و محصولات مستقل کوچک را ده برابر و سرعت تولید محصولات نهایی و آمادهی استفاده را حدود ۵۰٪ افزایش میدهد.
۲) فلسفهی نوین نرمافزار
شعار جدید تیمهای باهوش (smart) این است که “سریع حرکت کن و پاسخگو باش (move fast and be responsible.). ” این شعار به این معناست که نمونههایی (prototypes) در محیطی امن و ایزوله و خیلی سریع ساخته شوند و سپس به نمونههای مقیاسپذیر انتخابشده، ایمنی و امنیت افزوده میشود.
۳) کد در قالب فراورده (Artifact)
از آنجا که هوش مصنوعی میتواند کد را بنویسد، کد به عنوان یک خروجی، ارزش کمتری پیدا میکند. چنین اتفاقی باعث میشود تصمیمات مهم، مانند معماری یا طراحی پایگاه داده، بیشتر شبیه یک “درب دوطرفه” میشوند (یعنی برگشتپذیرند، به عبارت دیگر تصمیمهایی که اگر اشتباه باشند، میتوان بهراحتی اصلاحشان کرد). چنین قابلیتی امکان (iteration) تکرار بیشتر و حتا از نوسازی از ابتدا را فراهم میکند.
۴) گلوگاه (Bottleneck) جدید
همانطور که ساخت نرمافزار آسانتر میشود، تصمیمگیری در مورد اینکه چه چیزی بسازیم (what to build)، به بزرگترین گلوگاه تبدیل میشود. اِنگ این را “گلوگاه مدیریت محصول” (product management bottleneck) مینامد.
۵) افزایش و بهبود شهود (Honing Your Intuition)
توسعهدهندگان باید برای توسعه و افزایش شهود و قضاوت درونی خود از کاربران برای تصمیمگیری دربارهی محصولات تلاش کنند. هدف از جمعآوری دادههای کاربر، آموزش شیوهی قضاوت شماست، نه فقط استفاده از آنها برای تصمیمگیری در یک مورد خاص.
۶) یادگیری کدنویسی
این توصیه که مردم نباید کدنویسی یاد بگیرند زیرا هوش مصنوعی آن را خودکار خواهد کرد، “یکی از بدترین توصیههای شغلی تاریخ است.” هر گام خودکارسازی (از اسمبلی گرفته تا زبانهای سطح بالاتر و هوش مصنوعی) کدنویسی را با ارزشتر و در دسترستر کرده است.
۷) مهارتهای ضروری در آینده
مهمترین مهارت در آینده این است که بتوانید به یک کامپیوتر دقیقن بگویید که از او انتظار دارید چه کاری انجام دهد(tell a computer exactly what you want it to do). دانستن زبان کامپیوتر و کدنویسی، درک عمیقتری برای کنترل دقیقتر ابزارهای هوش مصنوعی فراهم میکند.
۸) نقش مهندس هوش مصنوعی (AI Engineer)
ما با کمبود “مهندس هوش مصنوعی” رو به رو هستیم. مهارتهای مورد نیاز برای این نقش نوظهور عبارتند از: آشنایی با کدنویسی به کمک هوش مصنوعی، تخصص در بلوکهای ساختاری هوش مصنوعی (AI building blocks, including RAG, agent workflows)، مهارتهای نمونهسازی سریع (rapid prototyping skills) (از جمله دانش پایه فولاستک – basic full-stack)، و مهارتهای اولیه مدیریت محصول و قضاوت کاربر (user judgment).
۹) مهندسی سریع (Rapid Engineering):
اندرو اِنگ اصطلاح “مهندسی سریع” (Rapid Engineering) را به “وایب کدینگ” (vibe coding) ترجیح میدهد. او فرایند کار با دستیارهای کدنویسی هوش مصنوعی را به عنوان یک “تمرین فکری عمیق” (deeply intellectual exercise) توصیف میکند، نه صرفاً تکیه بر “احساسات” (vibes)
ویدیو:
Andrew Ng: From Code to Product in Hours – The New Reality of AI Development
https://news.1rj.ru/str/bibalan_com
https://bibalan.com/?p=4875
https://bit.ly/3KvxVkp
پیشگفتار:
سیاهی لشکر نیاید به کار
یکی مرد جنگی به از صد هزار
اندرو اِنگ (Andrew Ng)، بنیانگذار DeepLearning.AI و یکی از بنیانگذاران Google Brain، پیام روشن و در عین حال چالشبرانگیزی برای توسعهدهندگان نرمافزار که نظارهگر دنیای هوش مصنوعیاند دارد:
“هوش مصنوعی جایگزین توسعهدهندگان نرمافزار نخواهد شد، اما توسعهدهندگان نرمافزاری که از هوش مصنوعی استفاده میکنند، جایگزین کسانی خواهند شد که استفاده نمیکنند. آینده کدنویسی، سمفونی بین حل مسئله توسط انسان و ظرفیت هوش مصنوعی برای اجرای سریع آنهاست. ارزش اصلی شما از نوشتن کد به معماری، اشکالزدایی و مهمتر از همه، هدایت دستیارهای هوشمند تغییر میکند. یاد بگیرید که به زبان هوش مصنوعی صحبت کنید تا به یک مهندس ۱۰-برابر قویتر تبدیل شوید.”
این بخشهایی است از سخنرانی اندرو انگ با عنوان «از کدنویسی تا محصول در چند ساعت — واقعیت جدید توسعهی مبتنی بر هوش مصنوعی» که برخی از نکات مهم آن را در زیر آوردهام.
گفتار: نکات کلیدی اندرو اِنگ برای توسعهدهندگان:
اِنگ در این گفتگو، مهارتهای عملی، تغییرات فلسفی و گلوگاههای نوظهوری را که توسعهدهندگان باید برای ماندن در خط مقدم بدانند، توضیح میدهد. متن زیر برداشتی است آزاد از صحبتهای ایشان.
۱) تمرکز و نگاهی نو بر سرعت
سرعت، بزرگترین پیشبینیکننده (predictor) موفقیت برای پروژههای نوآورانه است. هوش مصنوعی عامل افزایش این سرعت است: سرعت ساخت نمونههای اولیه و محصولات مستقل کوچک را ده برابر و سرعت تولید محصولات نهایی و آمادهی استفاده را حدود ۵۰٪ افزایش میدهد.
۲) فلسفهی نوین نرمافزار
شعار جدید تیمهای باهوش (smart) این است که “سریع حرکت کن و پاسخگو باش (move fast and be responsible.). ” این شعار به این معناست که نمونههایی (prototypes) در محیطی امن و ایزوله و خیلی سریع ساخته شوند و سپس به نمونههای مقیاسپذیر انتخابشده، ایمنی و امنیت افزوده میشود.
۳) کد در قالب فراورده (Artifact)
از آنجا که هوش مصنوعی میتواند کد را بنویسد، کد به عنوان یک خروجی، ارزش کمتری پیدا میکند. چنین اتفاقی باعث میشود تصمیمات مهم، مانند معماری یا طراحی پایگاه داده، بیشتر شبیه یک “درب دوطرفه” میشوند (یعنی برگشتپذیرند، به عبارت دیگر تصمیمهایی که اگر اشتباه باشند، میتوان بهراحتی اصلاحشان کرد). چنین قابلیتی امکان (iteration) تکرار بیشتر و حتا از نوسازی از ابتدا را فراهم میکند.
۴) گلوگاه (Bottleneck) جدید
همانطور که ساخت نرمافزار آسانتر میشود، تصمیمگیری در مورد اینکه چه چیزی بسازیم (what to build)، به بزرگترین گلوگاه تبدیل میشود. اِنگ این را “گلوگاه مدیریت محصول” (product management bottleneck) مینامد.
۵) افزایش و بهبود شهود (Honing Your Intuition)
توسعهدهندگان باید برای توسعه و افزایش شهود و قضاوت درونی خود از کاربران برای تصمیمگیری دربارهی محصولات تلاش کنند. هدف از جمعآوری دادههای کاربر، آموزش شیوهی قضاوت شماست، نه فقط استفاده از آنها برای تصمیمگیری در یک مورد خاص.
۶) یادگیری کدنویسی
این توصیه که مردم نباید کدنویسی یاد بگیرند زیرا هوش مصنوعی آن را خودکار خواهد کرد، “یکی از بدترین توصیههای شغلی تاریخ است.” هر گام خودکارسازی (از اسمبلی گرفته تا زبانهای سطح بالاتر و هوش مصنوعی) کدنویسی را با ارزشتر و در دسترستر کرده است.
۷) مهارتهای ضروری در آینده
مهمترین مهارت در آینده این است که بتوانید به یک کامپیوتر دقیقن بگویید که از او انتظار دارید چه کاری انجام دهد(tell a computer exactly what you want it to do). دانستن زبان کامپیوتر و کدنویسی، درک عمیقتری برای کنترل دقیقتر ابزارهای هوش مصنوعی فراهم میکند.
۸) نقش مهندس هوش مصنوعی (AI Engineer)
ما با کمبود “مهندس هوش مصنوعی” رو به رو هستیم. مهارتهای مورد نیاز برای این نقش نوظهور عبارتند از: آشنایی با کدنویسی به کمک هوش مصنوعی، تخصص در بلوکهای ساختاری هوش مصنوعی (AI building blocks, including RAG, agent workflows)، مهارتهای نمونهسازی سریع (rapid prototyping skills) (از جمله دانش پایه فولاستک – basic full-stack)، و مهارتهای اولیه مدیریت محصول و قضاوت کاربر (user judgment).
۹) مهندسی سریع (Rapid Engineering):
اندرو اِنگ اصطلاح “مهندسی سریع” (Rapid Engineering) را به “وایب کدینگ” (vibe coding) ترجیح میدهد. او فرایند کار با دستیارهای کدنویسی هوش مصنوعی را به عنوان یک “تمرین فکری عمیق” (deeply intellectual exercise) توصیف میکند، نه صرفاً تکیه بر “احساسات” (vibes)
ویدیو:
Andrew Ng: From Code to Product in Hours – The New Reality of AI Development
https://news.1rj.ru/str/bibalan_com
https://bibalan.com/?p=4875
👍7❤4