Спільна робота над документами в Google Документах

Коли кілька людей готують один документ, пересилання файлів створює плутанину: у кого остання версія та які правки вже враховано? Вебредактор дає змогу працювати зі спільним файлом і керувати доступом до нього.

Документ для команди

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

Як організувати роботу

1. Створіть документ у Google Документах.
2. Відкрийте налаштування спільного доступу та додайте потрібних учасників.
3. Оберіть права відповідно до ролі кожного учасника.
4. Узгодьте, хто приймає остаточні зміни й готує завершену версію.

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

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

Відкрити Google Документи · Довідка Google про спільний доступ

Переклад вебсторінок за допомогою Google Перекладача

Матеріал іноземною мовою не обов’язково читати зі словником у кожному реченні. Google Перекладач допомагає ознайомитися з текстом вебсторінки іншою мовою.

Як перекласти сайт

На комп’ютері відкрийте Google Перекладач, оберіть режим перекладу вебсайтів, задайте мови та вставте адресу потрібної сторінки. Доступність функції залежить від пристрою й регіону. Інший варіант — вбудований переклад у браузері Chrome.

Переклад як допомога в читанні

Машинний переклад зручний для першого знайомства з матеріалом. Водночас назви функцій, терміни, заперечення, числові значення та фрагменти коду варто звіряти з оригіналом. Помилка в одному слові може змінити зміст інструкції.

Для власної публікації переклад потрібно відредагувати: перевірити термінологію, логіку викладу та посилання. Технічні команди й адреси не слід перекладати як звичайний текст.

У 2007 році я випробовував переклад вебсторінок Google на власному сайті nerusoft.com, зокрема з російської на англійську. Можливість відкрити переклад цілої сторінки одразу допомагала показати матеріал іншій аудиторії. Для якісної публікації, однак, важливо не лише отримати автоматичний результат, а й перевірити його зміст.

Google Перекладач · Як перекладати документи й вебсайти

Як перевірити MX-записи домену та знайти причину проблем із поштою

MX-записи домену визначають сервери, на які має надходити вхідна електронна пошта. Якщо листи не доходять після зміни провайдера або налаштувань DNS, спочатку перевірте, які записи повертає DNS.

Перевірка через nslookup

У командному рядку виконайте:

nslookup -type=MX example.com

Замість example.com вкажіть свій домен. Щоб запитати конкретний DNS-сервер, додайте його адресу другим аргументом:

nslookup -type=MX example.com 1.1.1.1

Порівняйте результат із записами, які вимагає ваш поштовий провайдер. Зверніть увагу на імена серверів і пріоритети. Відповіді різних DNS-серверів після зміни налаштувань можуть тимчасово відрізнятися через кешування.

Інтерактивний режим і порівняння DNS-серверів

Якщо потрібно виконати кілька запитів поспіль, запустіть інтерактивний режим. Команди нижче вводяться по одній; символ запрошення > набирати не потрібно:

nslookup
set type=mx
example.com
server 1.1.1.1
set type=mx
example.com
exit

Перший запит використовує типовий DNS-сервер комп'ютера, другий — явно вказаний резолвер. Щоб перевірити сервер, який обслуговує зону вашого домену, замість 1.1.1.1 вкажіть його адресу. Так можна порівняти відповіді, а не робити висновок за одним кешованим результатом.

DNS і робота поштового сервера — різні перевірки

Правильний MX-запис ще не доводить, що сервер приймає листи або що вони потрапляють у скриньку адресата. Окремо перевірте налаштування поштового сервісу, доступність потрібних з’єднань та журнали доставки.

У дописі 2007 року я розділяв перевірку DNS, вихідного SMTP-з'єднання з поштового сервера та вхідного з'єднання до нього. Для діагностики TCP-порту 25 використовувався Telnet:

telnet <ім'я_зовнішнього_smtp_сервера> 25

telnet <ім'я_вашого_поштового_сервера> 25

Другу перевірку виконують із зовнішньої мережі. Сам факт відкритого TCP-з'єднання показує доступність порту, але ще не підтверджує доставку листа. Відповідь 220 — привітання SMTP-сервера, після якого потрібно аналізувати відповіді на команди.

Фрагмент SMTP-прикладу з нотаток 2007 року

У процитованому тоді матеріалі форуму networkdoc.ru був такий приклад. Назви серверів і дата в привітанні належать саме тому прикладу:

telnet smtp.mail.ru 25

220 mail.ru ESMTP Wed, 01 Dec 2004 20:57:02 +0300

ehlo test.test.ru
mail from: a@b.com
rcpt to: m@il.ru
data
Subj: Test
this is a test message.

Це скорочений фрагмент діалогу, а не повне готове повідомлення: стандартний заголовок теми має вигляд Subject: Test, заголовки відділяються від тіла порожнім рядком, а дані завершуються окремим рядком із крапкою. Для завершення сеансу використовується QUIT. У інструкції Microsoft з перевірки SMTP через Telnet наведено послідовність команд і відповідей.

Перевіряйте лише власний або дозволений для діагностики сервер та використовуйте власні тестові адреси. Параметри підключення, автентифікації та шифрування визначає поштовий провайдер; Telnet не шифрує сеанс, тому вводити в ньому пароль не слід. Перевірка серверного SMTP на порту 25 і налаштування поштового клієнта — різні завдання.

Що додати до звернення про помилку

Вкажіть домен, час перевірки, використаний DNS-сервер, версії операційної системи й поштового ПЗ, схему підключення через маршрутизатор, результат команди та точний текст помилки доставки. Так буде простіше відокремити проблему DNS від налаштувань сервісу.

Документація Microsoft: nslookup

Корпоративна пошта Google на власному домені: що потрібно для налаштування

У вересні 2007 року я натрапив на сервіс Google, який особливо зацікавив мене можливістю створити корпоративну пошту на власному домені. Адреса залишалася своєю — наприклад, name@example.com, — а читати листи можна було у зручному вебінтерфейсі Google.

Що вразило під час першого знайомства

На моєму домені nerusoft.com тоді можна було створити до 500 користувачів із поштовими скриньками по 2 ГБ. Для невеликої команди це виглядало дуже привабливо: власний домен, знайомий вебінтерфейс, додаткові сервіси й сервери, які обслуговує Google. Замість підтримки власного поштового сервера потрібно було розібратися з підключенням домену та його DNS-записами.

Сьогодні цей напрям розвивається в Google Workspace. Обсяг сховища й кількість користувачів визначає обраний план; цифри з мого досвіду 2007 року описують саме тодішнє підключення.

Що потрібно для пошти на своєму домені

Для налаштування Gmail у Google Workspace потрібні доступ до керування доменом та права адміністратора сервісу. Після підключення домену налаштуйте MX-записи відповідно до офіційної інструкції та активуйте Gmail у консолі адміністратора.

MX-записи вказують, куди доставляти вхідні листи. Google зазначає, що поширення змін може тривати до 72 годин. Якщо пошта вже працює зі старими підтримуваними MX-записами Google, змінювати їх лише через появу нової схеми не потрібно.

Поточні інструкції, доступні редакції та умови використання перевіряйте на сайті постачальника:

• Google Workspace
• Офіційна інструкція з налаштування MX-записів