Чому верстка дизайну сайту потребує часу: макет, браузери та CMS

«Порізати дизайн — це просто, тут небагато роботи». Я часто чув таку оцінку, але на практиці все залежить від вимог. Одне діло — відтворити просту картинку в одному вікні браузера, зовсім інше — зробити повноцінну сторінку для живого порталу. Ще у 2007 році я виділив чотири основні джерела цієї складності.

Від малюнка до структури сторінки

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

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

Важлива й швидкість завантаження. У 2007 році я наводив приклад: великий графічний градієнт часто можна було замінити маленьким зображенням із повторенням. Це зменшувало обсяг відповідної графіки. Сьогодні простий градієнт можна створити без окремого растрового файла функцією linear-gradient() у CSS. Завдання залишилося тим самим — відтворити задум без зайвих витрат на завантаження, хоча інструменти змінилися.

Різні браузери та версії

У 2007 році мені доводилося перевіряти сторінки, зокрема, в Internet Explorer, Opera та Firefox. Відмінності відображення між браузерами й версіями змушували витрачати час на налагодження та компроміси.

Отже, готовність макета ще не означала готовності шаблону: потрібна була перевірка фактичної поведінки в середовищах користувачів.

Текст і доступність вмісту для пошуку

Ще одна спокуса того часу — зібрати весь сайт у Flash, де легше було зафіксувати розташування об’єктів. Але керований вигляд не замінює доступного тексту й зрозумілої структури сторінки. Я наполягав, що основний контент потрібно представляти засобами HTML, CSS і JavaScript, а не ховати його всередині графічної композиції.

Для нового сайту питання Flash уже закрите: Adobe припинила підтримку Flash Player 31 грудня 2020 року й заблокувала відтворення Flash-контенту в ньому з 12 січня 2021 року. Практичний висновок ширший за цю технологію: основний текст і навігація повинні залишатися частиною вебсторінки, а не лише зображенням її зовнішнього вигляду.

Інтеграція з CMS

Меню, новини й основний контент порталу формуються динамічно. Тому дизайн потрібно узгодити з правилами шаблонів, компонентами та модулями конкретної CMS, а також із різними станами даних.

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

Наприклад, дизайнер намалював меню на п’ять коротких пунктів, а CMS отримала дванадцять довгих назв із підменю. Або блок новин має вміщувати і коротке повідомлення без фото, і великий матеріал з ілюстрацією. Це не «поганий контент», а стани, які шаблон має обробляти. Якщо їх не погодити заздалегідь, витрати з’являться вже під час інтеграції.

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

Gmail в Outlook та інших поштових клієнтах: підключення і параметри POP/SMTP

У 2007 році я звернув увагу, що поштою Google можна користуватися не лише через вебінтерфейс, а й у клієнтах на кшталт Outlook або The Bat. У тодішній нотатці згадував скриньку обсягом 2 ГБ і налаштування POP/SMTP. Серверні адреси залишаються корисними, а підключення тепер слід починати із сучасного способу авторизації.

Почніть із входу через Google

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

Якщо потрібен саме POP

У вебналаштуваннях Gmail відкрийте розділ пересилання та POP/IMAP, увімкніть POP для потрібних повідомлень і визначте, що робити з копіями листів у Gmail. Перевірте цей вибір до завантаження великого архіву.

• Сервер вхідної пошти: pop.gmail.com, порт 995, SSL.
• Сервер вихідної пошти: smtp.gmail.com. Поточна довідка POP наводить порт 587 із TLS/STARTTLS та автентифікацією.
• Ім’я користувача — повна адреса електронної пошти.

Для SMTP також використовується порт 465 із SSL/TLS — саме такий варіант був у моєму прикладі 2007 року. Не змішуйте налаштування: для 587 вибирайте STARTTLS, для 465 — SSL/TLS. Перевіряйте назви режимів у своєму клієнті; правильний порт не замінює належної авторизації.

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

Додавання Gmail у поштовий клієнт · Офіційні параметри POP · Протоколи й порти Gmail

Аналіз відвідуваності сайту: від лічильників до змістовних висновків

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

Чому одного лічильника було мало

У вересні 2007 року на своєму сайті nerusoft.com я використовував статистику самої CMS і доповнював її кількома зовнішніми лічильниками. Хотілося бачити не лише загальну кількість завантажених сторінок, а й те, хто приходить на сайт і як ним користується.

У моєму тодішньому досвіді phpNuke показував загальне число отриманих сторінок без поділу на пошукових роботів і людей. У «Бітрікс» я бачив докладніші категорії та деталізацію. Тому результати різних систем потрібно було порівнювати обережно: однакове слово «відвідування» ще не означало однаковий спосіб підрахунку.

Що я помітив у сервісах 2007 року

• Bigmir.net. Мені подобалися докладна статистика та власний рейтинг. Водночас ліміт дзеркал був замалим для мого набору сайтів, а частину відвідувань я не знаходив у звітах. Причину розбіжностей тоді не встановив.
• i.ua. Привертали увагу Ajax та різні зрізи статистики: інтерфейс здавався швидким і зручним. Дозволений список піддоменів був більшим, ніж у Bigmir, але мені все одно бракувало його обсягу.
• Mail.ru. Лічильник мав свій рейтинг і виглядав скромніше за частину інших інструментів. Для мого завдання корисним був облік усіх дзеркальних доменів.
• SpyLog. У моїй конфігурації також охоплював усі домени. Були безкоштовний і платний варіанти; у безкоштовному набір звітів був обмеженим. Окремо подобався показник користувачів, які перебували онлайн одночасно.
• Rambler. Для мене це був простіший лічильник із невеликою кількістю показників. Можливостей перевірити походження підсумкового числа відвідувань мені бракувало.
• Google. Не показував видимого лічильника на самій сторінці, зате пропонував цікаві графіки та акцентував основні показники. У моїх звітах враховувалися всі потрібні домени.

Що означає короткий візит

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

Але короткий візит сам по собі цього не доводить. Людина могла швидко знайти відповідь або перейти за потрібним посиланням. Висновок залежить від мети сторінки: коротка контактна довідка й великий навчальний матеріал виконують різні завдання.

У сучасній Google Analytics 4 показник залучення враховує час активної взаємодії. Його варто розглядати разом із призначенням сторінки, джерелами переходів і потрібними бізнесу діями. Перед порівнянням звітів перевірте налаштування збору даних та визначення показників — загальної кількості відвідувань для оцінки якості сайту недостатньо.

Довідка Google про залучення користувачів у GA4

Віддалений супровід програм: як організувати консультацію та доступ

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

Розмова, демонстрація та керування

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

Від адміністрування до консультації

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

З цього не випливає, що будь-який віддалений доступ потребує статичної зовнішньої IP-адреси або завжди дає всі права. У документації Radmin 3.x розрізняються режими Full Control і View Only, а з’єднання через маршрутизатор має власні мережеві налаштування. Дозволи й спосіб підключення потрібно оцінювати для конкретного засобу та конфігурації.

Наприклад, Microsoft Quick Assist дозволяє показати екран, а за окремим дозволом користувача — передати керування. Використовуйте такі підключення лише з перевіреним фахівцем, якого ви самі запросили допомогти.

Порядок консультації

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

Офіційна довідка Microsoft Quick Assist

Застосування системи «Корпорація 2»: модульна архітектура та плани 2007 року

У вересні 2007 року ми активно розробляли систему «Корпорація 2». Що далі просувалася робота, то більше ми бачили можливостей її застосування: модульна архітектура мала слугувати основою для різних програм, а не лише для бухгалтерського обліку.

Невеликий завантажувач і окремі плагіни

Завантажувач програми тоді займав лише 45 КБ. Невеликий модуль відповідав за підключення плагінів, які могли бути написані різними мовами програмування. Основну ідею ми бачили в тому, щоб додавати прикладні можливості окремими модулями й повторно використовувати спільну основу.

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

«Корпорація» встановить сама себе

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

Виходило кумедно: інсталятор «Корпорації» теж мав стати програмою «Корпорація». Отже, «Корпорація» встановить сама себе! Саме ця можливість повторного використання власних механізмів добре передавала задум розробки 2007 року.

Розробка «Корпорації 2»: ядро, плагіни та плани 2007 року

У вересні 2007 року «Корпорація 2» створювалася як повністю переписана версія програми «Корпорація 1.x». Ми вже створили ядро-завантажувач і працювали над прикладними модулями.

Завантажувати лише потрібні частини

Програму планувалося поділити на змістові частини — плагіни. Один модуль міг складатися з багатьох таких компонентів. Це давало змогу підключати лише потрібне для конкретного завдання, а окремі блоки, зокрема антивірусний, — вимикати, коли вони не були потрібні для обраного сценарію.

Наведені тоді вимірювання

Я тоді порівнював версію 1.0.4.77 з експериментальним завантажувачем «Корпорації 2». Для старої версії було зазначено розмір програми 23,4 МБ і такі значення використання пам’яті: 25,7 МБ після запуску, 1,8 МБ у згорнутому стані та 4,5 МБ після повторного розгортання.

Для нового завантажувача без підключених плагінів наводилися 4,8 МБ у звичайному стані та 696 КБ у згорнутому. Розмір виконуваного файла становив 45 КБ, а окремі плагіни могли мати розмір близько 25 КБ.

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

Формати та інструменти розробки

Описувалися плагіни у форматах BPL і DLL. Серед інструментів для їх створення називалися Delphi, C та Free Pascal. При цьому сумісність бібліотеки залежить від формату й інтерфейсу взаємодії, а не лише від вибору мови.

До постачання також планували додати IDE та варіанти компільованих і інтерпретованих рішень. Як можливі напрями застосування розглядалися робота з базами даних, графікою та 3D, навчальні програми, ігри, аналітичні застосунки й CAD-системи. Передбачалася як окрема, так і інтегрована робота середовищ.

Строки, сумісність і бази даних

Точної дати релізу не було: орієнтиром називався кінець 2007 року. Паралельно мала розвиватися гілка 1.0.5. Після випуску «Корпорації 2» планували зупинити її розвиток, зберегти потрібні можливості та забезпечити конвертацію баз 1.0.5 у версію 2.x.

Ядро задумувалося незалежним від конкретної СУБД, а плагіни могли використовувати різні бази. Ми розглядали Firebird, PostgreSQL, MySQL, Microsoft SQL Server та Oracle.

«Корпорація 2» і гілка 1.0.5: цілі розвитку у 2007 році

У вересні 2007 року «Корпорація 2» розроблялася паралельно з гілкою «Корпорація 1.0.5». Ці напрями мали різні ролі: проміжне вдосконалення наявної програми та підготовку нової архітектури.

Основні цілі «Корпорації 2»

• Побудувати ефективну розподілену структуру застосунку.
• Відокремити ядро від конкретної бази даних і прикладних завдань.
• Розширювати програму без перекомпіляції ядра.
• Спростити командну розробку завдяки поділу рішень на модулі.
• Зменшити вимоги до ресурсів і підвищити швидкодію роботи з даними.

Роль версії 1.0.5

Гілка 1.0.5 розглядалася як проміжний етап між версіями 1.x і 2.x. У ній планувалося реалізувати частину підготовлених змін, однак структура застосунку ще мала залишатися монолітною.

Таблиці в менеджері звітів: розвиток аналітики «Корпорації» у 2007 році

У вересні 2007 року менеджер звітів системи «Корпорація» отримав табличне представлення даних на додаток до OLAP-кубів. Це розширювало вибір способу роботи з результатами запиту.

Три способи подання даних

Для кожного рядка налаштувань куба можна було передбачити три варіанти відображення:

1. OLAP-куб для багатовимірного аналізу.
2. Таблицю з фільтрацією, сортуванням і групуванням.
3. Друкований звіт.

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

Що планувалося далі

Серед можливих наступних удосконалень розглядалися підсумки в заголовках груп, побудова графіків за табличними даними та багатовимірні таблиці. Остання можливість була віддаленим задумом без визначеного строку реалізації.

Плани версії 1.0.5: прайс-листи та простий облік коштів

Давно хотів реалізувати два окремі модулі — формування прайс-листів і простий облік коштів. Задум здавався нескладним, але до нього ніяк не доходили руки. У вересні 2007 року, працюючи над розвитком «Корпорації», я повернувся до цих планів: поділ програми на плагіни мав спростити не лише розробку, а й подальшу підтримку таких рішень.

Формування прайс-листів

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

Серед запланованих варіантів розрахунку називалися середня ціна або мінімальна ціна з торговельною націнкою. Також розглядалися інтеграція з інтернет-магазинами та автоматичне формування сайтів на основі накопичених даних.

Простий облік коштів

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

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

Контекстна реклама у 2007 році: навчання та акредитація в Begun

У вересні 2007 року я пройшов навчання й акредитацію в системі контекстної реклами Begun. Для нашої компанії це був крок до партнерства з рекламним майданчиком і розвитку власних послуг інтернет-реклами.

Від навчання до власних кампаній

Поряд із Begun ми налагоджували роботу з рекламними системами Meta, Google, Yandex і WebAlta. Тоді ми розглядали ці майданчики як канали для розміщення контекстної реклами й подальшої партнерської роботи.

Першим практичним майданчиком для перевірки підходів була наша власна компанія та її сайт nerusoft.com. Ми рекламували себе, оцінювали результат і поступово відпрацьовували свої методики просування в інтернеті. Навчання давало основу, а власні кампанії — досвід, який можна було застосовувати в наступних рекламних проєктах.

«Корпорація 1.0.5»: план архітектурних змін 2007 року

У вересні 2007 року розпочалася розробка гілки «Корпорація 1.0.5». Ми планували суттєво переробити внутрішню структуру програми, її оновлення й адміністрування. Головне завдання полягало в тому, щоб дати системі більше можливостей для розширення, не ускладнивши щоденну роботу з нею.

Плагіни та оновлення

Модулі планувалося винести в окремі плагіни, які підключав би невеликий завантажувач. Розширення програми мало стати гнучкішим, водночас оновлювати довелося б багато бібліотек замість одного виконуваного файла.

Система оновлень мала працювати не лише з базою ROffice.gdb, а й з іншими базами та файлами клієнтського робочого місця. В інсталяторі планувалося прибрати зайвий запит перезавантаження, пов’язаний зі старими Windows 95/98.

Дані, налаштування та адміністрування

• Централізувати зберігання налаштувань користувачів на сервері.
• Спростити адміністрування баз даних.
• Дозволити централізовано призначати права користувачам у філіях.
• Зменшити обсяг журналів, зберігаючи змінену інформацію.
• Переглянути перевірки цілісності заради швидкодії на великих базах.

У великих базах перевірка коректності даних після кожної зміни забирала помітний час. Тому в плані 2007 року було максимально скоротити використання тригерів контролю цілісності. Це створювало окреме інженерне завдання: приріст швидкодії потрібно було узгодити зі збереженням коректності даних.

Зв’язок, реєстрація та документація

Для розподіленої бази планувалося використання SSH2. Реєстраційний код мали зробити коротшим і прибрати його залежність від часу.

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

Спільна робота з календарями та документами Google: досвід команди

У вересні 2007 року наша команда почала використовувати інструменти Google для спільної роботи з інформацією. Основними напрямами були планування часу та ведення документів.

Спільний календар

Календар допомагав фіксувати події та узгоджувати використання часу. Події можна було вести індивідуально або разом з іншими учасниками.

Таблиці й текстові документи

Спільні таблиці та документи дозволяли працювати з інформацією в табличному й текстовому вигляді. Для робочої групи тоді використовувалися адреси http://www.google.com/calendar/hosted/nerusoft.com та http://docs.google.com/a/nerusoft.com.

Перші враження від швидкодії

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

RSS та Atom для обміну публікаціями: досвід 2007 року

У 2007 році на нашому сайті nerusoft.com ми щодня імпортували новини та теми з різних форумів. Обмін через стрічки допомагав наповнювати портал, а в матеріалах залишалися посилання на сайти, звідки надходила інформація.

Імпортувати чуже й поширювати своє

Стрічка працює у двох напрямках: сайт може читати публікації іншого ресурсу або надавати власні записи для читачів та агрегаторів. Для такого обміну використовуються RSS і Atom — формати подання вебконтенту на основі XML.

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

Як ми шукали додаткове охоплення

Тоді я пропонував організувати RSS форуму й подати його до сервісу Яндекса. У нотатці була адреса подання http://blogs.yandex.ru/add.xml. Ще одним варіантом розміщення був RSS-каталог i.ua за адресою http://rss.i.ua/live/. Саме такі канали поширення ми розглядали у вересні 2007 року.

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

Поширення та пошуковий рейтинг — різні результати

Я пов’язував обмін із популярністю й цитованістю сайту. Проте наявність стрічки або посилання сама по собі не вимірює цей результат. Корисніше перевіряти фактичні переходи та подальші дії відвідувачів, а не обіцяти приріст пошукового «вагового» показника після подання URL.

Для технічного налаштування допоможуть специфікація RSS 2.0 і формат Atom у RFC 4287. Вони описують обмін даними; рішення конкретного каталогу про прийняття стрічки залежать від самого сервісу.

Регулярні зупинки Apache: як у 2007 році помітили закономірність

У вересні 2007 року на сервері нашого порталу nerusoft.com з’явилася дивна закономірність: щонеділі приблизно між 7:30 та 8:00 припиняв працювати Apache. Причина залишалася незрозумілою, зате час повторювався надто чітко, щоб ігнорувати його.

Що ми вже знали

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

Через такі зупинки портал міг не відкриватися приблизно з 7:30 до 8:10. Я сподівався згодом знайти причину. Принаймні закономірність уже вдалося помітити — це була відправна точка для подальшого пошуку.

Як досліджувати подібну періодичність

У схожій ситуації варто зіставити точний час зупинки із записами журналу помилок Apache та системними подіями. Потім перевірити завдання за розкладом, резервування й ротацію журналів. Це напрями перевірки, а не встановлена причина нашого випадку.

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

Як працював сервіс «Відгуки» Яндекса: спостереження 2007 року

У вересні 2007 року я звернув увагу на цікаву функцію «Відгуки» в панелі інструментів Яндекса. Відкривши вебсторінку, можна було подивитися частину згадок про неї — зручний спосіб помітити, де обговорюють сайт.

Звідки з’являлися згадки

У моїх перевірках сервіс показував повідомлення з окремих форумів і блогів. Звісно, це була лише частина інформації, а не все, що писали про сторінку в інтернеті.

Наприклад, коли я додавав до публікації цього блогу адресу http://nerusoft.com, помічав відповідну згадку у «Відгуках». Для мого тодішнього прикладу було достатньо вказати URL сторінки :)

Я припускав, що деякі форуми потрапляли до сервісу після окремої заявки, але цього не перевіряв. Так само власний вдалий приклад не пояснював усіх правил відбору посилань. Сервіс допомагав знаходити окремі обговорення, проте не давав повної картини згадок.

Інцидент із сайтом на phpNuke: нотатка вересня 2007 року

У вересні 2007 року наш сайт на phpNuke знову зламали. На щастя, на той момент я не помітив значних пошкоджень; такі інциденти в нас траплялися нечасто.

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

Переспрямування вебсторінок: HTTP-редиректи та приклад meta refresh

Переспрямування, або редирект, переводить відвідувача з однієї адреси на іншу. Воно потрібне, зокрема, після перенесення сторінки або зміни структури сайту.

Основний спосіб — відповідь HTTP

Якщо є доступ до налаштувань сервера, використовуйте відповідний код стану 3xx і заголовок Location. Для постійного перенесення застосовують, зокрема, 301 або 308, для тимчасового — 302 або 307. Вибір залежить також від того, чи потрібно зберегти метод запиту.

Приклад meta refresh

У звичайному HTML можна задати перехід через одну секунду:

<!doctype html>
<html lang="uk">
<head>
  <meta charset="utf-8">
  <meta http-equiv="refresh" content="1; url=https://example.com/">
  <title>Сторінку переміщено</title>
</head>
<body>
  <p>Сторінку переміщено. <a href="https://example.com/">Перейти вручну</a>.</p>
</body>
</html>

Адресу https://example.com/ замініть на свою цільову сторінку. Зверніть увагу: правильний атрибут має назву http-equiv.

У прикладі число 1 задає паузу в одну секунду. Для автоматичного переходу MDN рекомендує 0 з міркувань доступності: не кожен читач встигає прочитати повідомлення або скористатися посиланням під час короткої затримки. За можливості налаштуйте HTTP-редирект на сервері.

Що робити з помилкою 404

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

Документація MDN про переспрямування HTTP

Спільна робота над документами в 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-записів