English for Unison Language Developers

Unison порушує достатньо традиційних припущень — немає текстових файлів, немає версій залежностей, код ідентифікується за його хешом — що обговорення про нього часто потребують речення налаштування перед самим питанням, просто щоб встановити, яка незнайома концепція грає.

Ключовий словник

** Content- addressed code ** — модель Unison, де кожна функція визначається за допомогою геш- даних її власного синтаксичного дерева, а не за допомогою назви у файлі, отже перейменування функції ніколи не порушує нічого, що її викликає.

• “Ми перейменували цю функцію у всій кодовій базі, не торкаючись жодного виклику — нічого не залежить від назви, тільки від геш-коду.” *

** Менеджер баз коду (UCM) ** — інструмент, який замінює файлову систему і інструмент збирання коду Unison, зберігаючи визначення безпосередньо і надаючи команди для перегляду, редагування і перевірки їх. “Немає git diff для перегляду тут у звичайному сенсі — ми проходимо через зміну всередині менеджера кодової бази, який показує точно, які геші змінилися.”

** Ability ** — Механізм типізації Unison для опису ефекту, який може виконувати функція, наприклад, доступу до мережі або винятків, схожий за змістом на систему ефектів, перевіряється під час компіляції. “Компілятор відхилив цю функцію, тому що вона виконує мережевий виклик, але не була оголошена з можливістю Network — це не стандарт, це справжнє відсутнє оголошення.”

** Термін / визначення ** — фундаментальна одиниця коду Unison, одне значення з назвою або функція, збережена за допомогою гешування, це будівельний блок, з якого складається все інше — простори імен, залежності. “Замість того, щоб думати у файлах, думайте в термінах — кожна функція має своє власне незалежно збережене, незалежно гешоване визначення.”

** Розподілені обчислення ** — здатність Unison відправляти серіалізовану функцію, за її хеш- кодом, для запуску на віддаленому вузлі без необхідності того, щоб цей вузол вже мав відповідний розгорнутий код. “Ми не мали потреби розгортати новий код до робочих вузлів взагалі — ми відправили обчислення самостійно, за допомогою гешування, і робочий вузол отримав і запустив його безпосередньо.”

Звичайні фрази

• «Чи це насправді перейменування, чи логіка визначення також змінилася — оскільки це дасть йому інший хеш?»
• «Чи ми переглядаємо цю зміну в менеджері кодової бази, або намагаємося порівняти її як звичайний файл?»
• Чи цій функції потрібно декларувати здатність Network (або IO ), або це реальний ефект, якого у неї немає?
• Чи це один термін, чи ми випадково описуємо кілька визначення, з’єднаних разом?»
• «Чи ми відправляємо код до робітника, або просто відправляємо обчислення і дозволяємо його отримати за допомогою гешування?»

Приклади висловлювань

Пояснення безпеки рефакторів у перегляді:

• “Це чисте перейменування в Unison — геш ідентичний, отже, кожен існуючий виклик гарантовано продовжить працювати без перерозгортання.” *

Опис помилки можливості: “Збирання зазнало невдачі, оскільки ця функція викликає введення-виведення без оголошення можливості — це система типів, що ловить незадекларований побічний ефект.”

Вирівнювання розподіленого проекту: “Ми не керуємо версіями, розгорнутими на кожному робочому процесі — ми надсилаємо функцію за допомогою гешування, і робочий процес виконує все, що він отримує.”

Професійні поради

• Поясніть ** content-addressed code ** на початку, коли хтось входить на борт - більшість плутанини про те, як “перейменування не руйнують речі” слідує назад до незнання хешів, а не імен, є справжньою особистістю.
• Показувати людям ** менеджер кодової бази ** замість текстового редактора, коли вони запитують « де файл » — зазвичай такого немає в традиційному сенсі.
• Розглядати помилку компіляції ** ability ** як законне відсутнє оголошення, а не формальність — це зазвичай означає, що незадекларований побічний ефект дійсно існує.
• При описі розподілених можливостей, будьте точними щодо розподілених обчислень за допомогою гешування проти звичайного розгортання — вони вирішують різні проблеми, і їх змішування не підходить для опису дизайну.

Практичні вправи

1. Пояснити, чому перейменування функції у Unison ніколи не руйнує її виклики.
2. Описати, що таке здатність і чому відсутність однієї з них призводить до помилки збирання.
3. Напишіть речення, у якому пояснюється, як Unison передає обчислення віддаленому працівнику.

Національні мови: рідна мова для ненаціональних меншин

Основні концепції Unison — контент-адресований код, можливості і розподілений підхід — потужно виражені англійською мовою. Однак, переклад технічних ідей в плавне професійне спілкування може бути на диво складним, навіть для досвідчених розробників. Багато не-рідних носіїв стикаються з проблемами не тільки з окремими словами, але і з * способом *, в якому ці слова використовуються в спільному середовищі розробки. Легко впасти в шаблони, які звучать незграбно або не передають точно бажане значення. Розглянемо деякі спільні області, де зміни можуть зробити значну різницю, особливо при обговоренні змін коду і проектних рішень.

Однією з найчастіших проблем є надмірна залежність від буквальних перекладів. Безпосереднє перетворення фраз, таких як «кодове сховище» в «хранилище кода» (що перекладається як «сховище коду»), може звучати нелогічно в англійській дискусії. Замість цього, розробники, природно, використовують такі терміни, як «зберігання», «розташування даних», або просто посилаються на контент, що зберігається – «дані, адресовані контентом». Аналогічно, коли пояснюється можливість, фраза на кшталт «функціональність» може здатися надто формальною. Описуючи це як «що робить здатність» часто є яснішим і більш доступним. Іншою проблемою є використання дієслова в часі. Хоча минулий час часто використовується для виконаних завдань («Я перебудував модуль»), теперішній час («Я реалізував цю функцію») іноді може звучати занадто настійливо, особливо при запропонуванні зміни. Використання «Я додав» або «Я працюю над» передає більш спільний і попередній підхід.

Крім того, формулювання навколо потенційних проблем - помилок, помилок або несподіваної поведінки - потребує ретельного розгляду. Просто сказати «є помилка» часто є занадто тупим. Формування проблеми як «ми спостерігали несподіваний результат» або «ми зіткнулися з ситуацією, де…» дозволяє більш конструктивно обговорювати основні причини і рішення. Хорошим прикладом цього є описи PR: замість того, щоб сказати « Виправлено помилку », розгляньте « Виправлено проблему з неправильною серіалізацією даних, запобігаючи аваріям за певних умов ». Такий рівень деталізації показує ретельність і розуміння.

Нарешті, пам’ятайте, що коротка мова є ключем. Розробники цінують чітке спілкування; уникнення надто складних структур речень завжди буде оцінено. Сфокусуйтесь на ефективному передачі основної інформації.

# Example: Unison Content Lookup - Finding a file by its hash

unison lookup --hash <file_hash>

Ця команда, виконана в Unison CLI, демонструє основну функцію - локалізацію коду на основі його криптографічного гешування, фундаментальної концепції, що лежить в основі адресованого зберігання контенту. Це практична ілюстрація того, як розробники обговорюють і використовують ці концепції щодня.