Видавнича методологія
Як ми створюємо, переглядаємо і підтримуємо кожен шматок контенту на Coders Lingo — щоб ви могли довіряти тому, що ви навчаєтеся.
Прозорість того, як створюється освітній контент, не є формальністю - це основа довіри. Коли ви використовуєте Coders Lingo для підготовки до співбесіди на роботу, поліпшення мови перегляду коду або розширення вашого технічного словника, ви покладаєтеся на те, що наш вміст буде точним, актуальним і заснованим на реальних ситуаціях. Ви заслуговуєте знати, як саме створюється цей контент і які стандарти ним керують.
На цій сторінці пояснюється наш повний процес редагування: як ми вирішуємо, що слід включати, як ми пишемо і перевіряємо вправи, як ми визначаємо термінологію з інформаційних технологій, і як ми постійно оновлюємо все, що відбувається у світі технологій. Якщо ви знайдете щось, що не відповідає цим стандартам, ми хочемо знати — скористайтеся сторінкою контактів, щоб повідомити про це.
Як вибрати тему
Кожна тема на Coders Lingo починається з реального прогалини: словниковий запас або моделі спілкування, які не рідні носії англійської часто зустрічаються в професійних IT-командах, але не покриваються загальними курсами англійської мови.
Ми використовуємо структурований аналіз спільнот розробників, щоб визначити, що інженери насправді читають, пишуть і обговорюють англійською мовою:
Окрім аналізу спільноти, ми зосереджуємось на словниковому запасі, який спричиняє задокументовану плутанину для нерідних носіїв — терміни з обманними фальшивими друзями, фрази з сильними реєстровими наслідками (надто формальними або надто неформальними для даного контексту) і жаргон, який використовується непослідовно в різних піддисциплінах.
Запити на теми від користувачів збираються постійно і переглядаються щоквартально. Запити, які відповідають нашим критеріям актуальності — справжнє використання фахівцями з ІТ, справжня відстань від загальних ресурсів англійської мови — планується включити до наступної партії вмісту.
Як писати вірші
Кожна вправа на Coders Lingo заснована на автентичному використанні, а не на вигаданих прикладах. Процес створення кожної вправи складається з чотирьох кроків:
Опознайте реальний артефакт
Ми починаємо з фактичного документа: запит на витягування з GitHub, пост-мортем з публічного інженерного блогу, відповідь з Stack Overflow, витяг з RFC або звіт про помилку в стилі Jira. Мова вправ походить від того, як інженери насправді пишуть, а не від того, як підручники вважають, що вони повинні писати.
Перевірити на автентичність
Перед тим, як будь-яке вправне питання буде завершено, воно перевіряється на основі ряду первинних джерел: технічна документація з основних платформ (AWS, Google Cloud, GitHub, Atlassian), публічні інженерні блоги (Netflix Tech Blog, Engineering at Spotify, Stripe Blog, Meta Engineering) і гілки GitHub з питань видатних проектів з відкритим кодом. Основне питання, яке ми ставимо, таке: «Чи говорить або пише це англомовний інженер?»
Перевірка реєстру та контексту
IT англійська охоплює кілька регістрів — від формальної точності RFC або Architecture Decision Record до випадкової короткості повідомлення Slack або коментаря з одним рядком. Кожна вправа має контекстну мітку (перегляд коду, відповідь на інцидент, документація, спілкування з зацікавленими сторонами), щоб студенти розуміли не тільки що означає фраза, але і коли її використовувати.
Переглянути варіанти відповідей на правдоподібність
Для вправ з кількома варіантами відповідей, неправильні варіанти буде обрано, щоб відобразити типові помилки, які роблять носії мови, для яких мова не є рідною (а не довільні неправильні відповіді). Це робить вправи справді діагностичними: якщо ви виберете неправильну відповідь, пояснення говорить вам, чому відволікаюча фраза є правдоподібною, але неправильною у цьому конкретному технічному контексті.
Як визначити значення слів
Глосарій є авторитетним словником на цьому сайті. Наш процес визначення надає перевагу точності над короткістю і визнає неоднозначність, якщо вона справді існує в області.
Основні джерела інформації
Визначення посилаються на авторитетні джерела, де б вони не існували: MDN Web Docs для термінів веб-платформи, офіційна документація продукту для хмарних та платформових послуг, специфікації RFC для мережевого та протокольного словника, стандарти IEEE для формальних інженерних термінів, і визначення NIST для словника безпеки. Там, де існує первинне джерело, ми посилаємося на нього.
Спори і суперечки
Деякі слова з галузі інформаційних технологій є справді суперечливими. Різні фахівці по- різному визначають « мікросервіси ». У « безсерверному » є точне визначення, яке використовується постачальниками хмарних послуг, а також ширше розмовне значення. « Гнучкий » може означати багато речей, залежно від організаційного контексту. Якщо термін має як строге технічне визначення, так і поширене неформальне використання, ми документуємо і те, і інше і пояснюємо відмінність, а не прописуємо одне «правильне» значення.
Перехресні посилання з використанням спільноти
Для словників, специфічних для домену, ми перевіряємо їх за статистикою теґів Stack Overflow і кількістю тем GitHub, щоб підтвердити, що термін дійсно широко використовується, а не є нішовим або застарілим. Термін з 50,000+ Stack Overflow питань і 20,000+ GitHub репозиторіїв є частиною активного словника працюючих інженерів; термін, який з'являється тільки в старій документації, відповідно анотований.
Описовий, а не рекомендативний
Ми описуємо, як інженери насправді використовують словник, а не як стилістичний посібник каже, що вони повинні. Для неформальних термінів (наприклад, «як гоління», «bikeshedding», «footgun»), ми пояснюємо походження, поточні моделі використання і реєстр - без відмовляти учням від використання словникового запасу, який є справді поширеним в професійних контекстах.
Наші стандарти точності
Фактична точність технічного вмісту вимагає постійної дисципліни, а не тільки ретельного початкового написання. Наші стандарти точності стосуються як створення, так і підтримки вмісту:
- Технічні твердження пов'язані з первинними джерелами. Коли ми стверджуємо, що термін має певне технічне значення, ми посилаємося на джерело, яке його визначає — чи це RFC, документ специфікації, офіційна документація продукту, чи визнане посилання, як MDN Web Docs.
- Зміни в словнику анотуються за контекстом. Словниковий запас в IT розвивається швидше, ніж в інших галузях. Такі терміни, як «безсерверний», «хмарний», «DevOps» і «повний стек» змінювалися в обсязі і конотації з часом. Там, де значення терміну змінилося, ми відзначаємо історичний контекст разом з поточним переважним використанням.
- Використання базується на рамкуванні над рецептом. Замість того, щоб стверджувати, що певне використання є «правильним» або «неправильним», ми віддаємо перевагу формулюванням на кшталт «зазвичай використовується в контексті X», «краще у формальній документації», або «неформальне використання в командному чаті». Це відображає фактичну соціолінгвістичну реальність живого технічного словника.
- Помилки виправляються публічно і негайно. Коли фактична помилка повідомляється через нашу форму контакту, ми розслідуємо її з первинних джерел і виправляємо вміст протягом 7 робочих днів. Виправлення відзначені у нижній частині відповідної сторінки, де помилка була суттєвою.
- Граматичний зміст посилається на встановлені авторитети. Граматичні вправи переглядаються з використанням Cambridge English Grammar in Use (Murphy) і Practical English Usage (Michael Swan) для загальних правил англійської мови, а також зі стилями, що використовуються в технічному письмі (Google Developer Documentation Style Guide, Microsoft Writing Style Guide) для специфічних IT-конвенцій.
Як ми зберігаємо контент в потоці
Технологічний словник швидко змінюється. Термін, який з'явився два роки тому, тепер може бути стандартом; рамка, яка домінувала в описах робіт минулого року, може зменшуватися. Ми підтримуємо актуальність змісту за допомогою структурованого циклу перегляду:
6-місячні огляди категорій
Кожна основна категорія контенту — хмарне, безпека, фронт-енд, DevOps, бази даних — переглядається з поточною індустрією кожні шість місяців. Ми перевіряємо, чи набір слів все ще відображає те, що інженери зустрічають в описах робіт 2024–2025 років, репозитарах GitHub і технічній документації.
Оновлення словника за допомогою порогових значень
Нові глосарні терміни додаються, коли технологія або концепція перетинає визначені пороги прийняття: 10 000+ публічних сховищ GitHub, що використовують термін як основну тему, або 5000+ питань Stack Overflow, що містять термін. Ці пороги вказують на справжнє професійне поширення, а не на хибне уявлення.
Застаріла анотація словника
Замість вилучення слів, які стали не вживаними, ми анотуємо їх у контексті: « поширені до епохи контейнерів », « замінені X », « все ще використовуються в документації старої кодової бази ». Це корисно для інженерів, які працюють зі старими базами коду, які потребують розуміння історичного використання.
Щомісячні вправи
Нові вправи додаються щомісяця на основі запитів спільноти, нових технологічних словників і прогалин, виявлених під час квартального перегляду тем. Кожна нова партія перевіряється за тими ж стандартами, що і початковий вміст перед публікацією.
Виробництво в масштабах
Coders Lingo публікує тисячі сторінок словника, колокації, мови, і інтерв'ю-ролі - більше ніж одна людина могла б писати сторінку за сторінкою, тому ми прямо про те, як цей масштаб досягається. Вміст створюється пакунками: для кожного пакунка визначається тема і джерело, за допомогою процесу, описаним вище, створюється початковий чернетковий варіант відповідно до цього джерела, а потім пакунок проходить крок перегляду « людина- у- циклі » перед тим, як буде опубліковано. Рецензент перевіряє пакет на відповідність стандартам точності, наведеним на цій сторінці — автентичність джерела, правильність позначень регістрів, можливі відволікаючі фактори для тестів, послідовність термінології — і надсилає все, що не пройшло перевірки, назад на перегляд, а не відправляє його.
Перед тим, як нова партія буде запущена, її також перевіряють на дублікати і суперечності з існуючим словником і корпусом вправ. Якщо новий запис повторює або суперечить тому, що вже було опубліковано, ми виправляємо або вилучаємо дублікат замість того, щоб залишати обидві версії на сайті; це вже траплялося кілька разів, оскільки сайт зростав, включаючи вилучення дублікатів граматичних сторінок. Пакетне видання не означає, що кожна сторінка отримала таку ж індивідуальну перевірку, як і наші найкращі посібники — це означає, що кожна партія проходить через той самий процес перевірки перед публікацією. Звіти про помилки або дублікати проходять через той самий процес виправлення, який описано вище.
Хто створює цей контент
Контент Coders Lingo створюється практиками з безпосереднім професійним досвідом як в інженерії програмного забезпечення, так і в технічному спілкуванні англійською мовою. Наші принципи створення вмісту:
Якщо ви працюєте у галузі інформаційних технологій і бажаєте внести виправлення або нове вправу, ми будемо раді вам допомогти. Скористайтеся сторінкою контактів, щоб зв'язатися з нами.
Применяй на практике
Тепер, коли ви знаєте, як створено наш вміст, почніть ним користуватися. Виберіть свою роль і розпочніть з словника, який має найбільше значення у вашій щоденній роботі.