Блог ·
Майбутня дата не є розкладом виходу
Двадцять чотири опубліковані статті стверджували, що ще не вийшли. Розвʼязком став не планувальник, а збірка, яка відмовляється від таких дат назавжди.
Автор: Provibr
Кожна стаття на цьому сайті несе дату публікації у своєму заголовному блоці. Вона зʼявляється під назвою, входить до структурованих даних, які читає пошукова система, і є єдиною датою, яку карта сайту взагалі друкує. Вона має бути фактом.
Певний час двадцять чотири з них ним не були. Вони несли дати, розкидані на шість наступних днів, бо той, хто їх писав, мав на думці ритм публікації й вписав його у файл. По девʼять мов кожна, тобто двісті шістнадцять файлів. Кожна з тих сторінок була опублікована, придатна для обходу й проіндексована, і кожна казала роботові в машинно-читній формі, що вийшла в день, який ще не настав.
Ніде не було червоного. Збірка була зеленою, тести були зеленими, сторінки віддавалися. Єдиним, хто міг побачити суперечність, була машина, що читала сторінку, а машини не подають повідомлень про помилки.
Що казала історія
Найперше треба було встановити, яка з двох дат правдива. Це одна команда: спитати git, коли кожен файл додали вперше. Усі двадцять чотири додано того самого дня, трьома внесками, трьома колами тієї самої нічної роботи. Жодного шестиденного викочування не було. Розкид був наміром, вписаним у поле, відведене для спостережень.
Ця відмінність і є всією статтею. Поле, що записує те, що сталося, не може водночас виражати те, що ви плануєте, бо читач не відрізнить одне від одного, а робот тим паче.
Чому ми не збудували планувальник
Очевидне виправлення полягає в тому, щоб зробити дати правдивими, змусивши сайт їх шанувати: ховати статтю, доки не настане її дата. Тут це хибне виправлення з двох незалежних причин, і обидві варто виписати, бо першу легко проминути.
Цей сайт створюється статично. Сторінки складають один раз, під час збірки, і віддають як файл. Отже, брама на даті оцінюється під час збірки й більше ніколи. Опівночі не зʼявляється нічого; воно зʼявляється тоді, коли хтось збирає. Брама на даті дає, таким чином, не розклад публікації, а набір сторінок, яких немає, доки випадково не запуститься стороннє викочування.
Друга причина гірша. Ті двісті шістнадцять адрес уже було обійдено. Ховати їх до їхньої номінальної дати означає віддавати 404 протягом до шести днів на сторінках, які пошукова система вже бачила й проіндексувала. 404 на вже проіндексованій адресі не є «поверніться пізніше», це сигнал вилучення, і відновлення після нього коштує значно більше за виправлену неправду.
Отже, дати виправили на день, коли робота справді приземлилася, торкнувшись лише того рядка в кожному з двохсот шістнадцяти файлів, а замість того прибрали саму змогу написати майбутню дату.
Брама стоїть біля джерела й не має запасного виходу
Збірка вмісту тепер відмовляє будь-якій даті в заголовному блоці, пізнішій за день, у який вона збирає. Не попередження: невдала збірка з іменем файлу та обома датами в повідомленні.
Два невеликі рішення всередині заслуговують на назву. Вона порівнює з сьогоднішнім днем у власному часовому поясі проєкту, а не з UTC, бо стаття, що вийшла тут о пів на першу ночі, несе тутешню дату, а порівняння з UTC відхилило б файл у день його ж виходу. І свідомо немає жодного обходу: ні змінної середовища, ні прапорця. Запасний вихід у такому правилі використовують раз із доброї причини, а далі постійно, а розклад належить до переліку завдань, а не до заголовного блоку файлу, який уже передано.
Далі стоїть друга брама, у реєстрі, що складає опубліковані статті, і вона лишає осторонь кожну статтю, дата публікації якої ще в майбутньому. Це сітка для шляхів, що не проходять через збірку: файл, змінений вручну, злиття, що змішує два покоління, відновлена копія. Вона стежить лише за датою публікації, а не за датою зміни, бо друкарська помилка в полі дати не має змушувати вже проіндексовану сторінку зникати.
А ту другу браму оцінюють один раз, під час завантаження модуля у процесі збірки. Це написано в коментарі поруч, бо читач, що припустив би інше, зрештою напише саме той планувальник, проти якого цей розділ і виступає.
Дату, якої не вивести, краще опустити
Те саме коло робіт мало вирішити, яка дата, коли взагалі якась, належить сторінкам документації, що не мають жодного заголовного блоку. Претенденток було три, і всі три хибні.
| Претендентка | Чому вона хибна |
|---|---|
| Дата git складника сторінки | Змінюється при зміні назви класу й не змінюється, коли текст переїздить до файлу перекладу |
| Дата git каталогу перекладу | Один файл містить тисячі неповʼязаних текстів і тому змінюється безперервно з причин, чужих цій сторінці |
| Дата збірки | Щодня каже, що кожну сторінку написано сьогодні |
Отже, сторінки документації не несуть у своїх структурованих даних жодної дати публікації. Ніщо краще за правдоподібне число, бо правдоподібне число є тим, якого ніхто не перевіряє.
Те саме міркування вже керувало картою сайту. Сталі маршрути не несуть жодної дати зміни, і причина не в лінощах: їхній вміст є кодом, а їхній текст живе в девʼяти каталогах перекладу, тож будь-яка обчислювана дата йшла б за чимось іншим, ніж бачить читач. Пошукова система, що тричі забирає «змінену» сторінку й застає її незміненою, вчиться нехтувати полем, і тоді поле гірше за відсутнє на тих сторінках, де воно справжнє. Статті свою несуть, бо вона стоїть у заголовному блоці поруч із назвою, де той, хто переписує текст, її справді бачить.
Після цієї роботи покриття не змінилося зовсім: адреси статей несуть дату зміни, усе решта не несе жодної, точнісінько як раніше. Змінилося те, що двісті шістнадцять із тих дат були в майбутньому, а тепер жодна там не перебуває.
Ще одна суперечність, розвʼязана тотожністю
Під час перечитування структурованих даних виринув менший різновид тієї самої проблеми: на деяких сторінках автор і видавець були двома окремими особами без оголошеного звʼязку. Прочитані буквально, ті сторінки твердили, що статтю написало одне підприємство, а видало інше. Обидва тепер указують на той самий ідентифікатор. Ніхто не поскаржився б, і це все одно було нашим твердженням, що не відповідало дійсності.
Що ми занотували б
- Ніколи не класти намір у поле, що записує спостереження. Читач їх не розділить, і машина теж.
- Звіряти твердження з історією. Одна команда над історією файлів вирішила, яка з двох дат справжня, і вона суперечила всім двадцяти чотирьом файлам.
- Брама на даті на статично створеному сайті не є розкладом. Опівночі не зʼявляється нічого; воно зʼявляється при наступній збірці.
- Не ховати адреси, які вже проіндексовано. 404 на обійденій сторінці є сигналом вилучення, а лікування коштує більше за хворобу.
- Ставити браму там, де роблять помилку, валити збірку й не додавати обходів. Ставити другу браму далі для шляхів, що проминають першу.
- Опускати дату, якої не вивести чесно. Три правдоподібні джерела, хибні всі три, означають, що чесним виходом є жодного.
Для ясності про те, чим це є: це доглядання за публічним сайтом, а не функція продукту, і воно не змінило жодної поведінки, за яку хтось платить. Частина цього лишається недоведеною. Структуровані дані перевірено за їхньою власною схемою й перечитано вручну, а не справжнім роботом чи справжньою карткою попереднього перегляду. Нічого не виміряно за покажчиком пошукової системи, бо таке вимірювання триває тижнями, і ніхто не має його чекати, перш ніж прибрати неправду.
Із роботи над сайтом Provibr. Скільки коштує тримати шістнадцять тисяч текстів правильними девʼятьма мовами, є в шістнадцять тисяч ключів, девʼять мов, а як зіткнення номерів полів у протоколі лишалося прихованим, є в два раунди, один номер поля.