Як вимовляти SQL, GIF, nginx та інші складні технічні слова
Остаточна відповідь на питання SQL проти продовження, GIF з жорсткою або м'якою G, вимова nginx і ще 15 технічних термінів, які всі обговорюють.
Деякі технічні терміни мають одну правильну вимову. Інші мають два конкуруючих табори, обидва рівно дійсні. А деякі мають вимову, яка здивує майже всіх, коли вони почують її вперше. Цей посібник містить найпопулярніші, найчастіше обговорювані і найчастіше неправильно вимовлені слова з техніки — у контексті, який вам потрібен, щоб звучати впевнено.
Великі дискусії
Ці терміни справді розділилися спільноти. Ось стан кожної дискусії.
SQL — “продовження” або “S-Q-L”?
** Обидва широко прийняті **, але “продовження” є більш поширеним в мові.
- «Sequel» (/ˈsiːkwəl/) — використовується більшістю фахівців з баз даних, особливо в США. Походження: SQL було розроблено з мови під назвою SEQUEL (Structured English QUEry Language), і вимовлялося « sequel ».
- ** « S- Q- L » ** (вимовляйте) — також коректно, використовується більше у формальному контексті і документації.
На практиці: «Я знаю продовження» або «Я знаю S-Q-L» розуміються як один, так і інший. Для інтерв’ю використовуйте те, що використовує ваш інтерв’юер.
Зауваження щодо варіантів: PostgreSQL вимовляється «Post-gres-Q-L» — а не «Post-gres-quill». Частина SQL завжди буде вказано тут.
GIF — жорсткий G або м’який G?
** Творець пише м’який G (“JIF”). Інтернет переважно використовує жорсткий G (“GIF”).**
- « JIF » (/ dʒɪf /) — Стів Вілхайт, творець формату GIF, категорично заявив: « Це вимовляється JIF, а не GIF. » Він порівняв його з маркою арахісового масла.
- “GIF” (/ɡɪf/) — як його вимовляє більшість людей, вважаючи його “подарунком” без Т.
У технічному спілкуванні, або розуміється. Більшість розробників використовують жорстку G. Не сперечайтеся про це на стоячі - це не закінчиться добре.
Linux — «LIN-uks» або «LYE-nuks»?
** Сам Лінус Торвальдс вимовляє його як “LIN-uks” ** (/ˈlɪnʊks/).
Багато північноамериканських розробників кажуть «LYE-nuks» з звички (наслідуючи англійські правила фонетики для імені «Linus»), але якщо ви хочете підібрати вимову фінського творця, це коротка I: «LIN-uks.»
Всі слова неправильні
Це не дебати — є стандартна вимова, і більшість людей спочатку неправильно її розуміють.
nginx
** Праворуч: EN-jinx** (/ˈɛndʒɪŋks/)
X на кінці вимовляється як K+S, що дає вам « - inks » або « - jinx ». Це не « en- JEEKS » або « en- GEE- ex. »
Думайте про це як про “двигун” + “X”: en-jinX.
cache
Праворуч: КАШ (/kæʃ/)
Один склад, римується з “готівкою”. Ніколи не “готівка-ай” (це французьке слово caché). Ніколи не « ловити ». Кеш навігатора, кеш процесора, кеш Redis — всі вони вимовляються « KASH »
daemon
Праворуч: DEE-mun (/ˈdiːmən/)
Фоновий процес, запущений у системі Unix. Не “DAY-mon” або “DY-mon”. Це римується з “lemon”. Це слово походить з грецької міфології (демон був духом-наставником), а англійська мова йде шляхом грецької через латинську.
sudo
** Праворуч: SOO-doh** (/ˈsuːdoʊ/)
« Заміна користувача do ». « su » вимовляється як « sue », а « do » римується з « go ». Не « SOO- doo ». Ви почуєте обидва варіанти на практиці, але « SOO- doh » є стандартним.
cron
** Праворуч: КРОН** (/krɒn/)
Римується з “на”. Не з “КРОНА” (що в казках - це стара жінка). Задача CRON, фонова служба CRON, вкладка CRON — все це має один склад: KRON.
regex
** Праворуч: REE-jex** або ** REH-jex** — обидва в порядку
« Формальний вираз » скорочено. Перший склад зазвичай наголошується: REE-jex (американський) або REH-jex. Ви почуєте і те, і інше. Не говори “ре-ГЕКС”
tuple
** Праворуч: TUH-pul** або ** TOO-pul** — спільнота розділена
Цей варіант має справжній розкол серед спільноти розробників:
- «TUH-pul» (римується з «пара») — улюблене слово математиків, від латинського кореня слова
- «TOO-pul» (римується з «dupple») — поширений серед програмістів
Документація Python не офіційно визначає. На практиці використовуються обидва. Безпечний вибір у змішаній команді: “ТУХ-пул.”
char
** Праворуч: CHAR** (/tʃɑːr/)
Як у « charcoal ». Не « care » або « car ». Тип даних char = символ. Один склад, вимовляється як “чар” в “спалених деревах”
boolean
** Праворуч: BOO-lee-un** (/ˈbuːliən/)
Три склади: Бу-лі-ун. Названо на честь математика Джорджа Була. Не говори “бу-лі-ан” або “болі-і-ан”. Підкреслюй перший склад.
Акронім: Say the Letters
Більшість технічних абревіатур записано літерно:
| Acronym | How to say it |
|---|---|
| API | ay-pee-eye |
| HTTP | aitch-tee-tee-pee |
| CSS | see-ess-ess |
| HTML | aitch-tee-em-el |
| URL | you-ar-el |
| DNS | dee-en-ess |
| JWT | jay-double-you-tee |
| SSH | ess-ess-aitch |
| YAML | YAM-ul (spoken as a word) |
| JSON | JAY-son (like the name Jason) |
** Правило голосних звуків: ** Якщо акронім починається з голосного * звуку *, використовуйте « an » — не за правописом, а за звуком. Отже: “API”, “запит HTTP”, “запит SQL” (S звучить як “ess”), але “URL” (“U” звучить як “you”).
На практиці
Найкращий спосіб запам’ ятати вимову - це почути її в контексті. Пошукайте будь-який з них на Ви англійці — він показує реальні відео-кліпи носіїв мови, які використовують слово в реченні. Для технічних термінів, пошук «[term] pronunciation» на YouTube зазвичай повертає конференц-розмови, де слово виникає природно.
Практичний тест: якщо ви кажете слово на зустрічі і люди виглядають збентеженими або просять вас повторити, це сигнал. Якщо ніхто не мигає, то ви, ймовірно, достатньо близько.
На практиці: Навігація нюансів в технічній комунікації
Будьмо чесними – вивчення професійної англійської як розробника, особливо коли справа доходить до високоспеціалізованої термінології, може відчуватися як навігація в густому лісі. Це не просто знати визначення слів, таких як “SQL” або “nginx”; це розуміння того, як вони насправді використовуються в розмовах і документації. Багато нерідних носіїв знаходять себе зосередженими на точному правописі і граматиці, що захоплює, але іноді може призвести до надмірно формального або навіть стислої комунікації, яка не зовсім підходить для колег.
Ключовим елементом, який часто ігнорується, є тонка різниця між заявою * факту * і пропозицією * пропозиції *. Наприклад, якщо ви переглядаєте код іншого розробника, просто сказати «Це використовує SQL неправильно» не дуже корисно. Більш конструктивним підходом може бути: « Я помітив, що цей запит може отримати користь від індексу у стовпчику customer_id — це, ймовірно, покращить продуктивність і читабельність для майбутніх оновлень ». Ця фраза підтверджує існуючий код, одночасно пропонуючи конкретне, дієве поліпшення. Аналогічно, в обговореннях Slack про розгортання змін, заява «PR потрібно переглянути» є функціональною, але не має впливу. Замість цього спробуйте: « Чи може хтось переглянути цей PR, зосередившись на інтеграції з новими кінцевими точками API? Я додав деякі тести, щоб допомогти забезпечити сумісність»
Інша поширена область нерозуміння пов’язана з рівнями впевненості. Сказати «Це * буде * працювати» може звучати неймовірно впевнено і, можливо, вводити в оману. Майже завжди краще сформулювати речі як ймовірності або рекомендації: « Це * повинно * працювати, припускаючи, що структура даних залишається послідовною » або « Я * рекомендую * ретельно перевірити це з репрезентативним набором даних. » Ці м’які фрази передають професіоналізм і визнають потенційні складності без надмірного зобов’ язання. Врешті-решт, чітке спілкування полягає в тому, щоб передати своє розуміння ситуації і вести інших до найкращого рішення, а не диктувати одну «правильну» відповідь.
Нарешті, пам’ятайте, що контекст має величезне значення. Одне і те ж слово може мати різні конотації залежно від галузі, командної культури і навіть конкретного проекту. Спостереження за тим, як спілкуються старші розробники, читання добре написаної документації і активне пошуки зворотнього зв’ язку є неоціненними інструментами для вдосконалення ваших навичок спілкування у світі технологій. Це постійний процес навчання - приймайте нюанси!
# Example: Optimizing an nginx configuration using command-line arguments
nginx -s reload && echo "Reloading nginx configurations..."