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

در نهایت، این پرسش‌ها و اندیشه‌ها باید ما را به چالش بکشند تا از خودمان بپرسیم: «آیا آماده‌ایم که باورهای قدیمی را پشت سر بگذاریم و پول را به عنوان وسیله‌ای برای تحقق رویاهایمان در نظر بگیریم؟» تنها با این تغییر نگرش می‌توانیم از چرخه افسارگسیختگی اقتصادی رهایی یافته و به سوی توسعه و رشد فردی قدم برداریم. مسئولیت تغییر در دستان خودمان است؛ تنها کافیست با دیدی نافذ و پرسشگری بی‌وقفه، مسیر زندگی خود را به سوی معنایی عمیق‌تر بازنگری کنیم.

خلاصه این همه صحبت کردم بگم مراقب Peer Pressure ها تو تصمیمات مالیتون باشین.

تقریبا دارم به این نتیجه میرسم که طبقه Middle Class دولوپر‌ها با اومدن هوش مصنوعی دارند روز به روز ضعیف و ضعیف تر‌میشند.

پ.ن: منظورم از میدل کلاس سطح سینیوریتی نیست. منظور نوع کار هست.

یه ویس کوتاه درموردش بریم؟

صوت جلسه 20

مواردی که خارج از کتاب بهشون اشاره شد در جلسه.
- یادگیری عمیق تر الگوریتم هایی مثل rTree
- اهمیت یادگیری edge computing برای توسعه صحیح نیازمندی cache

♦️آلوده‌ترین سایت هسته‌ای ایالات متحده به بزرگترین مزرعه خورشیدی تبدیل می‌شود
Most Contaminated U.S. Nuclear Site Is Set to Be the Largest Solar Farm

Keith Schneider


#NYTIMES
خلاصه متن:
برنامه‌هایی برای تبدیل سایت هسته‌ای هنفورد، که به عنوان آلوده‌ترین سایت هسته‌ای ایالات متحده شناخته می‌شود، به بزرگترین مزرعه خورشیدی کشور در حال پیشرفت است. این پروژه پس از سال‌ها پاکسازی زباله‌های رادیواکتیو و شیمیایی در این تأسیسات، به رهبری شرکت هکات در حال اجراست. این شرکت به ۱۰۳۰۰ هکتار زمین دسترسی خواهد داشت و انتظار می‌رود که در سال ۲۰۳۰ پروژه به اتمام برسد و حدود ۲۰۰۰ مگاوات برق تولید کند. این مقدار تقریباً معادل تأمین برق تمام خانه‌های سیاتل، سانفرانسیسکو و دنور است. با این حال، ابهامات سیاسی و اقتصادی در مورد حمایت دولت از این پروژه وجود دارد، به ویژه در دوران ریاست‌جمهوری ترامپ که به دنبال رهاسازی تولید نفت و گاز بود. کارشناسان بر این باورند که این پروژه می‌تواند به اشتغال‌زایی و تأمین انرژی پاک برای منطقه کمک کند، اما خطرات ناشی از آلودگی‌های گذشته نیز باید در نظر گرفته شود. هکات به دنبال استفاده مجدد از زمین‌های هنفورد است و در عین حال، نیازهای انرژی منطقه را نیز مورد توجه قرار داده است. در نهایت، این طرح می‌تواند به عنوان یک الگوی موفق برای تبدیل سایت‌های آلوده به منابع انرژی تجدیدپذیر در آینده مورد استفاده قرار گیرد.

متن کامل فارسی:
‏https://jjs.pub/4558

#هنفورد #سایت_هسته‌ای #مزرعه_خورشیدی #انرژی_تجدیدپذیر #انرژی_پاک

‎دسته بندی
[#Technology] [#Government] [#Innovation]
‎[#فناوری] [#دولت] [#نوآوری]

DANESHAGAHI NEWS
Cup Of Jamshid
FULLY AUTOMATED BY AI AGENT
2024-2025
@daneshagahi_coj

♦️یک شغل جانبی رو به رشد برای فارغ التحصیلان کالج آمریکایی: اصلاح پاسخ های اشتباه هوش مصنوعی
A Growing Side Hustle For American College Grads: Fixing AI’s Wrong Answers

Richard Nieva
2025-03-06

#FORBES
خلاصه متن:
با پیچیده‌تر شدن مدل‌های هوش مصنوعی، وظایف مربوط به آموزش این سیستم‌ها نیز به چالش‌های بیشتری تبدیل شده است. شرکت Scale AI، با سرمایه‌گذاری 14 میلیارد دلار، به دنبال نیروی کار مستقر در ایالات متحده است. در این راستا، کارگران فریلنسر در پلتفرم Outlier برای ارزیابی و اصلاح پاسخ‌های هوش مصنوعی کار می‌کنند. به عنوان مثال، اسکات اونیل، یک فروشنده لوازم لوله‌کشی، ساعات زیادی را صرف رتبه‌بندی پاسخ‌های مدل‌های هوش مصنوعی می‌کند و درآمدی بین 300 تا 1000 دلار در هفته کسب می‌کند. این شرکت با هدف استخدام کارگران تحصیل‌کرده، به 87 درصد از کارگران خود که دارای مدرک دانشگاهی هستند، متکی است. همچنین، Scale به دنبال تقویت موقعیت ایالات متحده در زمینه هوش مصنوعی است و به جای برون‌سپاری، بر استخدام کارگران آمریکایی تمرکز دارد. با این حال، این شرکت با انتقادات و شکایات متعددی در زمینه شرایط کاری و سلامت روان کارگران مواجه شده است. پیمانکاران ادعا کرده‌اند که با محتوای آزاردهنده مواجه می‌شوند و از عدم حمایت کافی در زمینه سلامت روان رنج می‌برند. در پاسخ به این انتقادات، Scale به بهبود سیستم پرداخت و شفاف‌سازی نرخ‌ها اشاره کرده است. در نهایت، با وجود چالش‌ها، این شرکت به رشد خود ادامه می‌دهد و به دنبال شکل‌دهی به آینده هوش مصنوعی است.

متن کامل فارسی:
‏https://jjs.pub/4738

#Scale_AI #Outlier #هوش_مصنوعی #حاشیه_نویسی_داده #اقتصاد_گیگ

‎دسته بندی
[#AI] [#Technology] [#Business]
‎[#هوش_مصنوعی] [#فناوری] [#کسب_و_کار]

DANESHAGAHI NEWS
Cup Of Jamshid
FULLY AUTOMATED BY AI AGENT
2024-2025
@daneshagahi_coj

این توییت هادی جان رو باید طلا گرفت..

۱۰ برابر شدن سرعت TypeScript با پورت کامپایلر به GO

در این ویدئو Andres Hejlsberg (خالق تایپ‌اسکریپت و سی‌شارپ) توضیح می‌دهد که چگونه با پورت کردن کدهای کامپایلر TypeScript به GO، سرعت کامپایل را 10x بهتر کرده‌اند!

او همچنین توضیح می‌دهد که چرا زیرساخت JavaScript برای این کار مناسب نیست. در حقیقت این زبان بیشتر برای کارهای UI طراحی شده بوده و زیرساخت‌های لازم برای کارهای performance-intensive مانند این کار را ندارد.

برای من خیلی جالب بود خالق سی‌شارپ، زبان GO را برای این کار انتخاب کرده، پس مستندات مربوط به این تصمیم را خواندم.
https://github.com/microsoft/typenoscript-go/discussions/411

اولین نکته جالب این بود که چقدر بدون تعصب و با ذهن باز زبان‌های مختلف رو بررسی کردن.
با توجه به اینکه هر دو زبان‌ C#, GO از لحاظ پرفورمنسی بسیار خوب هستند، یکی از مهم‌ترین دلایل انتخاب GO تشابه بسیار بالای سینتکس آن با TypeScript بوده است.

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

از بین زبان‌های C#, GO و Rust، زبان گو تشابه سینتکسی بیشتری با تایپ‌اسکریپت داشته و در نهایت انتخاب شده.

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


https://www.youtube.com/watch?v=pNlq-EVld70

#مهران_داودی (لینکدین - بلاگ)

⁉️ برای بحث و تبادل نظر فنی در مورد این پست، نظرات خود را با ما در قسمت کامنت‌ها به اشتراک بگذارید.

کانال تلگرام:
@SoftwarePhilosophy

______

#کوته_نیوز

مدیرعامل آنتروپیک(Claude):

هوش مصنوعی تا یکسال آینده درِ برنامه‌نویس‌ها میذاره و میفرستتشون باغبونی.

@DevTwitter

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

ورنه خاموش است و خاموشی...

تیمی را می‌توان بهره‌مند از امنیت روانی (Psychological Safety) دانست که اعضایش احساس کنند می‌توانند آزادانه نظرات‌شان را بیان کنند، سؤال بپرسند، اشتباهات خود را بپذیرند و ایده‌های جدید مطرح کنند، بدون ترس از سرزنش، تمسخر یا تنبیه.

این مفهوم ابتدا توسط پروفسور دانشکده کسب‌وکار هاروارد، اِمی ادموندسون (Amy C. Edmondson) در دهه نود میلادی مطرح شد، اما تحقیقات اخیر نشان داده‌اند که در عصر پرشتاب تحولات دیجیتال، اهمیت آن بیش از پیش افزایش یافته است.

در مطالعه‌ای که در سال ۲۰۲۳ انجام شد پژوهشگران (کلارک و گروس)، از طریق بررسی داده‌های جمع‌آوری‌شده از ۴۸ تیم نرم‌افزاری در شرکت‌های فعال در حوزه فناوری دریافتند که تیم‌هایی با سطح بالای ایمنی روانی، تا ۳۵ درصد بهره‌وری بیشتری در حل مسائل پیچیده و نوآورانه از خود نشان می‌دهند.

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

چرا ایمنی روانی برای تیم‌های توسعه نرم‌افزار حیاتی است؟
فرآیند توسعه نرم‌افزار ماهیتاً پیچیده، تعاملی و وابسته به خلاقیت و حل مسئله مستمر است. در چنین محیط‌هایی:

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

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

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

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

ایمنی روانی به این معنا نیست که مهربان باشیم؛ بلکه به این معناست که بتوانیم با یکدیگر صادق باشیم.

با این حال، می‌توان با اتخاذ برخی اقدامات، مسیر را هموارتر کرد:

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

✅ بازخورد منظم و ایمن: نشست‌های بازاندیشی (Retrospective) باید فضایی فراهم کنند که اعضای تیم بتوانند آزادانه، بدون نگرانی از پیامدهای منفی، چالش‌ها، نگرانی‌ها و ایده‌های خود را بیان کنند. این جلسات زمانی موفق خواهند بود که از فضای داوری و سرزنش فاصله داشته باشند و بر تحلیل، یادگیری و بهبود مستمر متمرکز شوند.

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

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

پی‌نوشت:

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

- روح‌الله دلپاک
@DelpakLog

صوت جلسه 21
جلسه به شدت جذابی بود، البته همه جلسات جذابیت زیادی داره ولی این یکی بدلیل موضوع به شدت چالش برانگیزش، جذاب تر شد.

مواردی که خارج از کتاب بهشون اشاره شد در جلسه.
- دقت به بررسی معنایی خود عبارات Online transaction processing (OLTP) و online analytical processing (OLAP) و ایجاد مدل ذهنی صحیح از این کلمات و دقت به این موضوع که هر دو عبارت تقسیم های حوزه ابزار هستند و در علوم کامپیوتر جایگاهی ندارند همانند دیگر کلمات حوزه ابزار مثل Cloud
- اشاره به تفاوت دو کلمه Analytics و ANALYSIS که اینجا هم بهشون قبلا پرداختیم. هر چند در جلسه من به اشتباه تعریف دو کلمه را جابجا نسبت به قبلا گفتم که همینجا باید بگم دوستان دقت کنند، هر چند در انتها به توافق با بهنیا عزیز هم نرسیدیم که دقیقا این مرز را قائل بشیم یا نه، هر چند در وجود دو نیازمندی #داده_اکتشافی گذشته نگر و آینده نگر قطعا اتفاق نظر داریم.

ابزار مدیریت محصول Linear که یکی از استارت‌آپ‌های خیلی موفق چند سال گذشته است، به خاطر نگاه متفاوتی که به روند توسعهٔ محصولشون داشتن در کامیونیتی‌های پروداکت و UX خیلی ازش صحبت می‌شه. اونا تونستن که محصول خیلی باکیفیتی ارائه بدن و خیلی‌ها معتقدن از رقیب‌های بزرگشون مثل Jira و Clickup تجربهٔ کاربری بهتری ارائه می‌دن.

یک محصول خوب با پشتیبانی یک تیم مهندسی خوب ساخته می‌شه. Sabin Roman که Engineer Manager و Hiring Manager این شرکته، اخیراً مصاحبهٔ خیلی خوبی با Gergley Orosz داشته. هر دوی این افراد در گذشته در Uber با هم همکار بودن و به همین دلیل مقایسه‌های جالبی بین شرکت بزرگی مثل Uber و استارت‌آپ نسبتاً جدیدی و کوچکی مثل Linear شکل می‌گیره.

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

ویدیو رو می‌تونید از این لینک ببینید.

@aminrbg

به نظرم Linear برای مدیریت روال های توسعه نرم افزار خیلی خارق العادس، به نظرم فیچر های خیلی خوبی داره مثل نگهداری Issue ها به صورت دوطرفه هم داخل گیتهاب و هم داخل Linear.
من توی مایگریشنم از Notion به Linear خیلی خوشحالم.

حالا میخوام یه ترکیب برنده رو بگم برای تیم های ریموت کوچیک.

Linear + Slack + WorkWeave + Github


Linear: Task management
Slack: Team comunication
WorkWeave: Team Performance Measurment
Github: Issue management, Code management.

جدای از 1 لایه و 2 لایه و 15 لایه، یا 6 ضلعی و 20 ضلعی و غیره، یا حتی کثیف و تمیز و تمیزتر،

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

این حرف نبی رو باید با الماس گرفت (طلا کمه)