خرسِ برنامه نویس
https://sam-cooper.medium.com/the-country-that-broke-kotlin-84bdd0afb237
فرض کنید شما به انجام یک سری محاسبات بسیار پیچیده ریاضی نیاز دارید، برای این کار سراغ دو ریاضیدان، یکی در شرق کره خاکی و دیگری در غرب میرید. مسئله رو برای هردو بیان میکنید، با در نظر گرفتن اینکه مسئله برای شما یک جواب واحد داشته باشه آیا جواب هر دو ریاضیدان باید یکی باشه؟ آیا منطق و ریاضیات وابسته به نقطه جغرافیایی کار میکنه؟ یعنی جواب ۲ + ۲ در شرق از غرب متفاوته؟ تو ساعت های مختلف چطور؟ (رجوع کنید به formal system ها)
نرم افزار ها چطور؟ آیا انتظار دارید کد شما در غرب یک جور کامپایل شه و در شرق یک جور دیگه؟ اگه نرم افزار رو یک جعبه خیلی بزرگ در نظر بگیریم که یک ورودی میگیره و یک خروجی ثابت میده (یک Pure function بزرگ)، دیگه فرق میکنه که که این جعبه کجای دنیا باشه؟ (لطفا رگولاتوری هارو درنظر نگیرید جلوتر به اون موضوع میرسیم)
این مقاله که امروز صبح خوندم خیلی جالب بود. به طور خیلی خلاصه داستان یک باگ رو میگه در کامپایلر زبان کاتلین که روی سیستم هایی که زبان ترکی داشتند، کاراکتر i و I اشتباها به معادل ترکیشون یعنی İ و ı مپ میشدند. مقاله جالبیه و به نظرم حتما بخونید.
 
اما مسئله ای که من میخوام بهش اشاره کنم که درون مایه این مقاله رو پوشش میده، مسئله Local Agnostic هست.
اول بگیم locale یعنی چی؟ میتونیم اینطوری تعریفش کنیم که هرچیزی که به یک منطقه، محیط یا کانتکست وابسته است و میتونه نسبت به مکان و یا نحوه اجرای نرم افزار متفاوت بشه، locale نرم افزار ما حساب میشه!
مثال های ساده ای هم ازش وجود داره: مثلا تایم زون، زبان سرور، کشور استقرار سرور، محیط و ...
درمورد رگولاتوری ها هم یک پرانتز باز کنم، رگولاتوری ها به معنی کلاسیک یک Locale حساب نمیشن یعنی system locale نیستن اما میتوان اونها رو به عنوان environment locale به حساب آورد چون در سطح جغرافیایی و سیاسی وجود دارند و باید اعمال بشن. مثلا شما با قوانین اروپا در آمریکا operate نمیکنی یا بالعکس پس من برای ساده سازی موضوع یک دسته بزرگی به اسم Environment Locale در نظر میگیرم که شامل System Locale هم میشه از اینجا به بعد با اسم Locale میریم جلو.
حالا که فهمیدیم locale دقیقا چیه میتونیم بپرسیم locale کجا ها مشکل آفرینه و چطوری میتونیم حلش کنیم؟ locale اونجایی مشکل میشه که تبدیل شه به یک ساید افکت کریتیکال در اجرای برنامه! یعنی چی ؟ یعنی اینکه نرم افزار شما برای درست اجرا شدن و رفتار غیر قابل پیش بینی نشون ندادن باید به این ساید افکت متکی باشه. مثلا باید حتما در تایم زون UTC+4 باشه و در تایم زون های دیگه خروجی های غیر منتظره میده و درست رفتار نمیکنه. توی همین مقاله این موضوع با زبان سیستم عامل تکرار شده.
حالا راه حل چیه؟
اینکه نرم افزار رو درجهتی توسعه بدیم که بیشتر و بیشتر به Locale Agnostic شدن نزدیک بشیم! یعنی چی؟ یعنی اینکه نرم افزار "آگاه" باشه از کانفیگ های سمت سرور و رگولاتوری های جغرافیایی ولی برای Operate کردن در هر نقطه از جهان به اون ها متکی نباشه! مثلا از تایم زون سرور برای ارسال و دریافت زمان استفاده نکنه. Locale-agnostic بودن یعنی abstract کردن این شکل تفاوتها، نه نادیده گرفتنشان.
این دست از ساید افکت ها خیلی نامرئی هستند حتی وقتی بهشون برخورد میکنیم که اصلا انتظارشو نداریم یا اصلا نمیدونیم که وجود دارند، شاید در حال حاضر اصلا برامون اهمیت نداشته باشن! اما حداقلا باید بدونیم که چنین چیز هایی وجود دارند و یک جای کوچکی براشون توی دیزاین و کد ریویو هامون درنظر بگیریم.
  
  نرم افزار ها چطور؟ آیا انتظار دارید کد شما در غرب یک جور کامپایل شه و در شرق یک جور دیگه؟ اگه نرم افزار رو یک جعبه خیلی بزرگ در نظر بگیریم که یک ورودی میگیره و یک خروجی ثابت میده (یک Pure function بزرگ)، دیگه فرق میکنه که که این جعبه کجای دنیا باشه؟ (لطفا رگولاتوری هارو درنظر نگیرید جلوتر به اون موضوع میرسیم)
این مقاله که امروز صبح خوندم خیلی جالب بود. به طور خیلی خلاصه داستان یک باگ رو میگه در کامپایلر زبان کاتلین که روی سیستم هایی که زبان ترکی داشتند، کاراکتر i و I اشتباها به معادل ترکیشون یعنی İ و ı مپ میشدند. مقاله جالبیه و به نظرم حتما بخونید.
اما مسئله ای که من میخوام بهش اشاره کنم که درون مایه این مقاله رو پوشش میده، مسئله Local Agnostic هست.
اول بگیم locale یعنی چی؟ میتونیم اینطوری تعریفش کنیم که هرچیزی که به یک منطقه، محیط یا کانتکست وابسته است و میتونه نسبت به مکان و یا نحوه اجرای نرم افزار متفاوت بشه، locale نرم افزار ما حساب میشه!
مثال های ساده ای هم ازش وجود داره: مثلا تایم زون، زبان سرور، کشور استقرار سرور، محیط و ...
درمورد رگولاتوری ها هم یک پرانتز باز کنم، رگولاتوری ها به معنی کلاسیک یک Locale حساب نمیشن یعنی system locale نیستن اما میتوان اونها رو به عنوان environment locale به حساب آورد چون در سطح جغرافیایی و سیاسی وجود دارند و باید اعمال بشن. مثلا شما با قوانین اروپا در آمریکا operate نمیکنی یا بالعکس پس من برای ساده سازی موضوع یک دسته بزرگی به اسم Environment Locale در نظر میگیرم که شامل System Locale هم میشه از اینجا به بعد با اسم Locale میریم جلو.
حالا که فهمیدیم locale دقیقا چیه میتونیم بپرسیم locale کجا ها مشکل آفرینه و چطوری میتونیم حلش کنیم؟ locale اونجایی مشکل میشه که تبدیل شه به یک ساید افکت کریتیکال در اجرای برنامه! یعنی چی ؟ یعنی اینکه نرم افزار شما برای درست اجرا شدن و رفتار غیر قابل پیش بینی نشون ندادن باید به این ساید افکت متکی باشه. مثلا باید حتما در تایم زون UTC+4 باشه و در تایم زون های دیگه خروجی های غیر منتظره میده و درست رفتار نمیکنه. توی همین مقاله این موضوع با زبان سیستم عامل تکرار شده.
حالا راه حل چیه؟
اینکه نرم افزار رو درجهتی توسعه بدیم که بیشتر و بیشتر به Locale Agnostic شدن نزدیک بشیم! یعنی چی؟ یعنی اینکه نرم افزار "آگاه" باشه از کانفیگ های سمت سرور و رگولاتوری های جغرافیایی ولی برای Operate کردن در هر نقطه از جهان به اون ها متکی نباشه! مثلا از تایم زون سرور برای ارسال و دریافت زمان استفاده نکنه. Locale-agnostic بودن یعنی abstract کردن این شکل تفاوتها، نه نادیده گرفتنشان.
این دست از ساید افکت ها خیلی نامرئی هستند حتی وقتی بهشون برخورد میکنیم که اصلا انتظارشو نداریم یا اصلا نمیدونیم که وجود دارند، شاید در حال حاضر اصلا برامون اهمیت نداشته باشن! اما حداقلا باید بدونیم که چنین چیز هایی وجود دارند و یک جای کوچکی براشون توی دیزاین و کد ریویو هامون درنظر بگیریم.
Medium
  
  The Country That Broke Kotlin
  Logic vs language: how a Turkish alphabet bug played a years-long game of hide-and-seek inside the Kotlin compiler
🤔3👌2
  Audio
    
  صوت جلسه 14 خوانش کتاب یادگیری تفکر سیستمی
مواردی که خارج از کتاب بهشون اشاره شد در جلسه.
- گفتمان علمی
- تخریب خلاق
مواردی که خارج از کتاب بهشون اشاره شد در جلسه.
- گفتمان علمی
- تخریب خلاق
🔥7
  فرصت نشد درمورد این مقاله باحال از Anthropic مطلب بنویسم، گفتم بزارمش که دیر نشه، فقط خیلی سوسکی بگم که LLM ها هم DDOS میشن!
https://www.anthropic.com/research/small-samples-poison
  
  https://www.anthropic.com/research/small-samples-poison
Anthropic
  
  A small number of samples can poison LLMs of any size
  Anthropic research on data-poisoning attacks in large language models
👍6🔥3
  Forwarded from TondTech (مسعود بیگی)
  
فعلا فقط نسخه macos ش اومده 
https://chatgpt.com/atlas?openaicom_referred=true
https://chatgpt.com/atlas?openaicom_referred=true
👍4❤2
  
  TondTech
فعلا فقط نسخه macos ش اومده  https://chatgpt.com/atlas?openaicom_referred=true
هیچ چیز دندون گیری نداشت، باید منتظر آپدیت موند.
🍾5😁3
  
  خرسِ برنامه نویس
https://aws.amazon.com/message/101925/ آنچه گذشت!
از این داستانی که بر آمازون گذشته تعابیر زیادی میشه داشت خیلی چیز هارو میشه سرزنش کرد (نکنید خواهشا)، میشه باد در گلو انداخت و راحت گفت آمازون هم میاد پایین! (نگید خواهشا!).
این صحبتا بد نیست باشه ولی فکر میکنم با Redundant کردن سرویس ها میشه تا حدودی از بیزنستون در قبال این جور داستان ها محافظت کرد! حالا اگه بیزنستون اونقدری بزرگ نیست که همچین حرکتی بخواید براش بزنین اشکال نداره، ولی حداقل به عنوان یه تصمیم ساز در نظر بگیریدش (یا با تصمیم ساز ها سازمانتون مطرحش کنین)
این صحبتا بد نیست باشه ولی فکر میکنم با Redundant کردن سرویس ها میشه تا حدودی از بیزنستون در قبال این جور داستان ها محافظت کرد! حالا اگه بیزنستون اونقدری بزرگ نیست که همچین حرکتی بخواید براش بزنین اشکال نداره، ولی حداقل به عنوان یه تصمیم ساز در نظر بگیریدش (یا با تصمیم ساز ها سازمانتون مطرحش کنین)
👍5❤1🔥1
  
  خرسِ برنامه نویس
https://techcrunch.com/2025/10/14/openai-has-five-years-to-turn-13-billion-into-1-trillion/?utm_source=chatgpt.com
الان OpenAI داره به ازای هر دلاری که درمیاره، سه دلار خرج میکنه.
همه این خرجا برای اینه که احتمالا تو افق چند سال آینده داره چیز بزرگتری میبینه.
اعداد جالبی بود!
همه این خرجا برای اینه که احتمالا تو افق چند سال آینده داره چیز بزرگتری میبینه.
اعداد جالبی بود!
👍2🔥1
  میکرو فرانت اند اگه جای اشتباه استفاده شه (که درمورد جای درستش هم بحث ها دارم) 
از ( استفاده اشتباه) میکروسرویس ها میتونه کشنده تر باشه!
از ( استفاده اشتباه) میکروسرویس ها میتونه کشنده تر باشه!
👍4🔥2
  👍5
  Forwarded from thisisnabi.dev [Farsi]
  
A friendly reminder to all of us building tech: power ≠ usability.
Daniel De Laney’s post “Normal” is going viral in tech — and for good reason.
He shows a TV remote with most of its buttons covered in tape. Only the essentials remain. It’s absurdly simple — and perfect for the person using it.
That image captures what’s wrong with most software: too many buttons, too much flexibility, too little empathy. Users don’t want optionality; they want clarity. They don’t want to “learn a system”; they just want it to work.
If you’re building for non-experts, design for the taped-over remote first. Hide complexity. Reveal it only when someone asks for it.
Software wins when it feels obvious. Everything else is just noise.
https://www.linkedin.com/posts/mariustreitz_a-friendly-reminder-to-all-of-us-building-activity-7389702679670796288-UvVU?utm_source=share&utm_medium=member_android&rcm=ACoAABdqDr0BJIj7gy7oW3facT7ro7bITsW3Ay0
Daniel De Laney’s post “Normal” is going viral in tech — and for good reason.
He shows a TV remote with most of its buttons covered in tape. Only the essentials remain. It’s absurdly simple — and perfect for the person using it.
That image captures what’s wrong with most software: too many buttons, too much flexibility, too little empathy. Users don’t want optionality; they want clarity. They don’t want to “learn a system”; they just want it to work.
If you’re building for non-experts, design for the taped-over remote first. Hide complexity. Reveal it only when someone asks for it.
Software wins when it feels obvious. Everything else is just noise.
https://www.linkedin.com/posts/mariustreitz_a-friendly-reminder-to-all-of-us-building-activity-7389702679670796288-UvVU?utm_source=share&utm_medium=member_android&rcm=ACoAABdqDr0BJIj7gy7oW3facT7ro7bITsW3Ay0
👍1🤔1