سلام به همه‌ی عزیزانم

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

بعد با چند نفر در لیست تماس من تماس گرفتند وبا آنها شروع به گفتگو (چت) کردند.

لطفا اگر پیامی از طرف من دریافت کردید آن را فراموش کنید.

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

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

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

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

حالا این روزها به یاد مادر، بارها این جمله‌ی او را با خود زمزمه کرده‌ام که «کو خاک بر سر ماره اولاده»

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

گفتار: تا نفس باقى است غلط بنويسيم
همين جورى چند جمله از يك كتاب‌.
او در جلوى كتابخانه منتظر مى‌ماند. و آن جا، با پالتوى كهنه و نيمدارش، دست به جيب، به ديوار تكيه مى‌دهد.

۱. ضمير ابتداى جمله زائد است. پيدا است كه من و شما ضمير فعل جمله نيستيم.
۲. چون لحن كتاب متمايل به‌سادگى لحن محاوره است «جلو» كافى و «در» زائد است.
۳. سر نرم پايان كلماتى چون جلو و چلو و دو و پالتو برخلاف ر و س در حالت اضافه به مصوت ِ«ىِ» نياز ندارد زيرا در اين حالت سىِ نيمه ملفوظِ انتهائى به حسىِ كامل تبديل مى‌شود: «جلوِ كتابخانه» «دوِ صدمتر» وگرنه: «جلوى» (=پيشين) و «چلوى» (=آن‌كه چلوپزد يا فروشد).
۴. جامه ابتدا نيمدار (=كاركرده) است پس از آن كهنه. نه اول كهنه و بعد نيمدار. تازه گيريم كه اين دو به يك معنى باشد، جمله را چرا بايد بى‌جهت سنگين كرد؟
۵. نقطه اول و هرسه ويرگول ميان جمله زائد است.
۶. اگر جمله به اين شكل نوشته مى‌شد عيبى داشت؟: «تو پالتوِ نيمدارش دست به جيب جلوِ كتابخانه به ديوار تكيه مى‌داد و منتظر مى‌شد.»

گزیده:
شب‌های تارِ نم‌نمِ باران ــ که نیست کار ــ
اکنون کدامیک ز شما
بیدار می‌مانید
در بسترِ خشونتِ نومیدی
در بسترِ فشرده‌ی دلتنگی
در بسترِ تفکرِ پُردردِ رازِتان

به نظر شما، بر اساس روز کاری ایده‌آل‌تان، شما در کدام دسته‌ از توسعه‌دهندگان زیر قرار می‌گیرید؟ ویژگی‌های کاری و شخصی شما به کدام گروه از توسعه‌دهندگان شامل توسعه‌دهندگان اجتماعی (Social)، تنها (Lone)، متمرکز(Focused)، متعادل (Balanced)، هدف‌گرا (Goal-oriented) یا رهبر (Leading) شباهت دارد؟

گزیده:
۲۰۱۱: نرم‌افزار داره دنیا رو می‌خوره. مارک اندریسون (Marc Andreessen)
۲۰۲۲: نرم‌افزار داره نرم‌افزاری رو که در حال خوردن دنیاست می‌خوره. جان اکارد (Jon Eckhardt)

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

یکی از متداول‌ترین مخالفت‌ها با نگرانی پیرامون هوش مصنوعی این است که «هوش مصنوعی در سطح انسان یا فراتر از آن غیرممکن است».
این یک ادعای غیرمعمول از سوی پژوهشگران هوش مصنوعی است و از زمان تورینگ تاکنون همین پاسخ را به نگرانی‌های فیلسوفان و ریاضی‌دانان داده‌اند. این ادعا که هیچ مدرکی پشتیبانش نیست، ظاهر اعتراف به این است که اگر هوش مصنوعی ابرهوشمند امکان‌پذیر می‌بود خطرات عمده‌ای در پی داشت. مثل این می‌ماند که راننده‌ای به مسافرانش بگوید «ما داریم به سمت پرتگاه می‌ریوم و ترمز ماشین بریده و کار نمی‌کند. اما به من اعتماد کنید، پیش از آن که به پرتگاه برسیم، بنزین‌مان تمام می‌شود و ماشین متوقف می‌شود!»
این ادعا نشانگر شرط‌بندی بی‌پروایی علیه نبوغ انسانی است. ما قبلا این شرط را بسته‌ایم و باخته‌ایم.
در ۱۱ سپتامبر ۱۹۳۳، ارنست راترفورد، فیزیکدان پرآوازه، با اطمینان کامل گفت «هر کس از تبدیل این اتم‌ها انتظار منبع توان داشته باشد، حرف پوچ و چرندی می‌زند.» در ۱۲ سپتامبر ۱۹۳۳، لئوسیلارد واکنش زنجیره‌ای هسته‌ای با القای نوترون را اختراع کرد و چند سال بعد چنین واکنشی را در آزمایشگاهش در دانشگاه کلمبیا نشان داد. او نشان داد که شکافت هسته‌ای به واکنشی زنجیره‌ای می‌انجامد. سیلارد در خاطراتش نوشته است: «ما همه چیز را خاموش کردیم و به خانه رفتیم. آن شب، هیچ شکی در ذهن من وجود نداشت که دنیا به سوی غم و اندوه روان شده است.»

استوارت راسل (Stuart Russell)، استاد دانشگاه برکلی، نویسنده معروف کتاب‌‌های هوش مصنوعی

منبع: کتاب تراوش‌های ذهنی، ۲۵ شیوه نگرش به هوش مصنوعی، فصل ۳
نوشته جان بروکمن، ترجمه استاد گرامی ابراهیم نقیب‌زاده مشایخ

خُب، مرتب‌سازی (tidying) چیست؟
بک با شوخ طبعی همیشگی‌اش توضیح می‌دهد: «هر مرتب‌سازی (tidying) یک بازسازی (refactoring) کوچولو موچولوی نازنازی نادقیق است. هر مرتب‌سازی یک تغییر در ساختار سیستم است که تغییر در رفتار سیستم را آسان‌تر می‌کند. هر کار از نوع «نخست‌ مرتب‌‌ کنید» (tidy-first) تلاش می‌کند ساختارِ کد را بدون ایجاد ترس و وحشت تغییر دهد.”

اجازه دهید مثالی را با هم مرور کنیم. فرض کنید با یک تابع (function) بزرگ که تعداد خط‌های آن زیاد است رو به رو هستید. قبل از تغییر آن، کد تابع را می‌خوانید تا بفهمید چه کار می‌کند و ببینید چطور می‌توانید آن‌را به طور منطقی به بخش‌های (chunk) کوچکتر تقسیم کنید.

توجه کنید که تقسیم کد به بخش‌های کوچک‌تر، یک «مرتب‌سازی»(tidying) ساده است. ما صمیمانه به شما پیشنهاد می‌کنیم به کانال YouTube ما بروید (https://youtu.be/VrkRAVX1h4I) و کل سخنرانی را تماشا کنید تا مثال‌های بیشتری از مرتب‌سازی با استفاده از عبارت‌های نگهبان (guard clause)، توضیح‌ کد (comment) یا توابع کمکی (helping function) را ببینید.

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

منبع کد: refactoring.guru

(مترجم؛ تابع کمکی (helping functions) تابعی است که بخشی از وظیفه‌ی تابع دیگری را انجام می دهد. توابع کمکی برای خوانایی بیشتر کد استفاده می‌شوند چون بخشی از کد تابع اصلی را جدا می‌کنند و نام جداگانه‌ و خوانایی به آن اختصاص می‌دهند. این توابع به شما اجازه می دهند از کد جداشده در تابع‌های دیگر نیز دوباره استفاده کنید.)

چرا تغییر نرم افزار پرهزینه است؟
برداشت دیگری که می‌توانید از این مفهوم طراحی نرم افزار داشته باشید این است که هزینه نرم افزار تقریباً با هزینه تغییر آن برابر است و توسعه اولیه تاثیر چندانی بر آن ندارد. با این حال، همه تغییرات یکسان و شبیه به هم نیستند: گاهی اوقات هزینه کل ایجاد یک تغییرِ “ارزان” تحت تاثیر هزینه‌‌های چند تغییر بسیار گران قرار می‌گیرد. از نظر فنی، توزیع هزینه ویژگی‌ها (features) از توزیع توانی (power law distribution) پیروی می‌کند. چرا برخی از تغییرات بسیار پرهزینه‌تر از بقیه تغییرات هستند؟

(مترجم؛ توزیع توانی در علم آمار، نوعی رابطه بین دو کمیت است که یک کمیت به صورت توانی از دیگری تغییر می‌کند. مثلاً مساحت یک مربع از دیدگاه طول ضلع آن را در نظر بگیرید، اگر طول دو برابر شود، مساحت آن چهار برابر (دو به توان دو برابر) می‌شود [ویکی‌پدیا])

ما همان اثر بهمن (avalanche effect) را در این رفتار مشاهده می‌کنیم، جایی که تغییر پارامترِ یک تابع باعث ایجاد تغییرات متعدد در سیستم می‌شود. رابطه‌ی بین اجزای نرم‌افزاری که باعث بروز و پخش تغییرات متعدد در سیستم می‌شود همان جفت‌شدگی (coupling) است. اما در کنار این وابستگی‌ها و جفت‌شدگی‌های اجزا، ما مشغول جداسازی‌ (decoupling) آنها هم هستیم. اگر به عقب برگردیم و با دقت نگاه کنیم به این نتیجه می‌رسیم که نقش طراحی نرم افزار، مدیریت تصمیم‌های بینابینی (tradeoff) جفت‌شدگی(coupling) /جداسازی(decoupling) است زیرا افزایش هر یک از آنها باعث افزایش هزینه می‌شود.

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

“بنابراین بین این دو یعنی جفت‌شدگی (coupling) یا جداسازی (decoupling) باید نقطه‌ی کمینه‌ی (minimum) هزینه را پیدا کنید. برای این تصمیم‌گیری باید توجه کنید که اگر جفت‌شدگی (coupling) وجود دارد ما باید برای کاهش آن سرمایه‌گذاری کنیم و در نتیجه لازم است هزینه جداسازی (decoupling) را افزایش دهیم تا بتوانیم به آن نقطه‌ی کمینه برسیم. و این توضیحات پاسخ به این سؤال است که «چرا باید نخست مرتب کنیم؟» و کنت بک با این جمله صبحت‌هایش را به پایان می‌رساند در حالی که ما نیز با صحبت‌هایش کاملا موافقیم.

حرف آخر
روش “نخست مرتب کنید” به بررسی تغییرات طراحی در ابعاد بسیار کوچک می‌پردازد و رابطه‌ی برنامه‌نویس با خودش را بررسی می‌کند. این روش چیزهای زیادی برای اندیشیدن و آموختن دارد اگر به دنبال یافتن راه‌هایی هستید تا به کمک آنها بتوانید پروژه‌ها و تیم‌های خود را بهتر مدیریت کنید.
به همین دلیل است که ما در Beetroot به دنبال ایجاد فرهنگی انسان‌محور هستیم تا تیم‌ها در کنار رشد و پیشرفت، با همدلی روی راه‌کارهای تاثیرگذار کار کنند. اگر شما یکی از این تیم‌ها را انتخاب کنید و به آن بپیوندید، ما می‌توانیم با هم کارهای فوق‌العاده‌ای انجام دهیم.

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

در مورد مرتب‌سازی (tidying)

سوال اصلی این است: “من می خواهم کدی را تغییر بدهم ولی ساختار کد به گونه‌ای است که تغییر آن دشوار است. آیا ابتدا باید کد را مرتب کنم؟” بِک ادامه می‌دهد “من در مورد بازسازی‌ (refactor) کدهای بزرگ صحبت نمی‌کنم. من در مورد تقسیم کدهای بزرگ و یک‌تکه به مایکروسرویس‌ها(microservice) و تصمیم‌های بزرگ و باشکوه در مقیاس بزرگ صحبت نمی‌کنم. من در مورد رابطه‌‌ی خودم با خودم صحبت می‌کنم. آیا برای خودم این ارزش قائل هستم که کارم را راحت‌تر کنم؟”با این اوصاف، برنامه نویسی نباید کاری اضطراب آور، دلهره‌آور و اعتماد به نفس خراب‌کن باشد. در نتیجه، قبول یک مساله‌ی پیچیده و شکستن آن به مساله‌های کوچکتر که درک آنها آسان‌تر است، عادت بی‌نهایت مفیدی است. او می‌گوید”اصطلاحی است که تقریباً ده سال پیش آن را پیشنهاد کردم: – MCETMEC تغییر را آسان کنید و بعد تغییر آسان را انجام دهید (Make the Change Easy Then Make the Easy Change).آسان کردن تغییر، قلمروی اصلی طراحی نرم افزار است. بنابراین به جای اینکه بخش‌های سخت و پیچیده را تغییر دهید که برای انجام آن هم مجبورید به صورت همزمان 100 جای سیستم را تغییر دهید، می‌توانید ابتدا کدها را مرتب کنید، هزینه ایجاد همه آن تغییرات را کم کنید و سپس یک تغییر آسان را انجام دهید.”

در توسعه نرم‌افزار، زمانی‌که از یک ایده (مثلا”من به یک دکمه در سیستم برای ویرایش اطلاعات نیاز دارم”) به تغییر(UX، گردش‌ کار و بک‌اند (backend) پشت آن) می رسیم، رفتار سیستم یعنی ویژگی‌های قابل مشاهده بیرونی آن -را تغییر می‌کنیم. تغییر در رفتار برنامه معمولا باعث ایجاد چرخه‌ای می‌شود که در آن، پیاده‌سازی هر ویژگی جدید باعث تولید مثل و تولد ویژگی‌های جدیدتری می‌شود. از سوی دیگر یک مسیر موازی و پنهان نیز وجود دارد که بخش ساختاری نرم‌افزار است (شبیه به کوه یخی که قسمت‌هایی از آن در زیر آب پنهان است). یکی از نکات زیبا و قشنگ در اینجا این است که ساختار نیز به‌تنهایی می‌تواند برای کارهای قابل انجام در سیستم، ایده‌‌هایی را پیشنهاد کند. و اگر بتوانید تمام این حلقه‌های بازخورد را با هم اجرا کنید، می‌توانید به سرعت کشف کنید که چگونه نرم‌افزار شما می‌تواند ارزش بیشتری خلق کند.

در چنین شرایطی ممکن است اختلالاتی هم رخ دهد. برخی از سبک‌های توسعه (development styles) روی حلقه “ایده → رفتار → ایده” تمرکز می کنند که باعث می‌شود دور باطلی ) از پیاده سازی ویژگی‌ها بدون توجه به ساختار سیستم ایجاد گردد. (مترجم؛ چرخ همستر یا دور باطل به فعالیتی گفته می‌شود که با انجام آن، شخص همیشه مشغول است اما هرگز به دستاورد مهم و ارزشمندی دست پیدا نمی‌کند و از سوی دیگر پایانی نیز برای آن فعالیت وجود ندارد.)

یکی دیگر از اختلالات، زمانی رخ می‌دهد که قبل از هر گونه پیاده‌سازی، تمام تلاش‌ها صرف تهیه‌ی یک طراحی کامل و بی‌نقص می‌شود (طراحی بزرگِ قبل از پیاده‌سازی، سلام! (Big Design Upfront)) در پی این تلاش‌ها، ساختارهای زیبا و خوش ساخت زیادی ایجاد می‌شوند در حالی که هیچ کاربرد و اهمیتی در پیاده‌سازی رفتارهای مورد نیاز کاربران ندارند. این روش سرمایه‌گذاری روی ساختارها، شما نه‌تنها بازده و منفعتی از سرمایه‌گذاری خود کسب نمی‌کنید بلکه بازخوردها را نیز به تاخیر می‌اندازید.

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

گزیده:
پیشنهاد می‌کنم ۱۰ تا ۲۰ درصد از کل زمان توسعه خود را صرف سرمایه‌گذاری [روی برنامه‌نویسی استراتژیک] کنید. این زمان آن قدر کم است که تأثیر چندانی بر برنامه‌‌ریزی‌ها ندارد، اما آن قدر بزرگ است که بتواند به مرور و در طول زمان، نتایج قابل‌توجهی به بار آورد.»
از کتاب فلسفه طراحی نرم افزار نوشته‌ی جان اوسترهات،