Як ми запускали Хабр для гуманітаріїв (з водолазами та виплатами для всіх)

«У наступні два роки потрібно не намагатися зобразити з себе щось особливе, а просто бути достатньо розумним, щоб компонувати те, що людство створило» © bobuk
Рік тому на внутрішньому хакатоне наші ростовські хлопці за ніч схрестили візуальний текстовий редактор, «Типограф Муравйова» антиплагіат-сервіс. Вийшла штука, яка допомагала швидко підготувати та надіслати публікацію в блозі.

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


Старий Гутенберг був би задоволений

Воно дозволяє людям читати цікаві історії, як дядько-водолаз 40 років підіймає затонулі кораблі в Баренцевому морі, а письменникам на популярні нетехнічні теми — трохи заробляти на текстах.

Давайте подивимося, що враховувати при розробці подібного сервісу, і що вибрати, щоб без милиць.

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

Чому з 10 редакторів варто вибрати Medium (JS)


Спасибі Муравйову за друкар (Python)


Як працює система " антиплагіат (Pytnon)


Як авторові зрозуміти, який ефект дають тексти

Як це підтримувати (про роботу з сисадмінами)


Історія про дядькові-водолазові (на uPages)

Але почнемо з початку. Коли сайд-проект став переростати в высоконагруженную платформу, з'явилося розуміння, що щось потрібно дописати і переписати.

0. Як ми вибирали технології
Ми розраховуємо, що вже до кінця року платформою скористаються 8 тисяч авторів, а читацька аудиторія наблизиться до 300 тисяч.

Ілля devhard, CTO uPages: «При виборі технологій для проекту ми виходили з таких міркувань: перспективність і стійкість до великих навантажень.

Вибір припав на зв'язку Node.js + MongoDB. На клієнті ніяких ангуляров, реактов, редуксов. В якості фреймворку вибрали Express.js з-за його минималистичности і наявності всього необхідного з коробки або з невеликими додатковими установками.

Також у нас були ESlint — утиліта, яка сильно допомогла привести код декількох розробників до більш-менш єдиного стилю без довгих суперечок в дусі «що краще: таби або прогалини». Дуже корисно на ранніх етапах розробки.

У ESlint є демка на сайті. Завантажити проект можна з GitHub.

Docker-контейнери — в якості робочого оточення для додатків проекту — щоб убезпечити себе від параної кшталт «оновимо бібліотеку і всі зламається» і при необхідності швидко отримати потрібні версії бібліотек або навіть кілька абсолютно різних збірок (грубо кажучи, stable і bleeding_edge складання).

Ще у нас було 3 Git-репозиторію (один локально в офісі, два — в різних дата-центрах). І я знав, що коли-небудь ми почнемо писати візуальний редактор».


1. Якщо ви вирішили написати свій власний WYSIWYG, ми вам співчуваємо
Сергій, наш розробник: «Прототип з хакатона робився для блогів і сайтів на uCoz. І природно, першим ділом ми подумали взяти щось звідти. Але, як відомо, частина uCoz написана на Perl — а ми вибрали Node.js. Значить, редактор довелося б підключати як окремий сервіс або переписувати.

Проглянувши ще з десяток варіантів, відкинули і їх, тому що:

  1. Вони або не були «що бачу, то і отримую» редакторами.
  2. Небудь з коробки виглядали не сучасно, а як Word 2003.
  3. Або кастомизировать їх — все одно що костылезировать.
Список редакторів, які ми не рекомендуємо, ви знайдете в першому коментарі, але один розкриємо прямо зараз:


CKEDITOR — не твій бро (хоча б унаслідок №2)

Авторами на майданчику будуть різні люди — і профі-журналісти та копірайтери, і зовсім новачки, і ті, хто пробував блогерствовать в суворі 2000-е. Хотілося зробити редактор таким, щоб кожен міг завантажити статтю швидко і без зайвої метушні.

Пошукавши ще, ми зрозуміли, що на весну 2016-го вибір був однозначний — Medium Editor, опенсорсний редактор, натхненний популярної однойменної блог-платформою. На перший погляд, в ньому одні плюси.

У ME досить повна і зрозуміла документація, проект постійно допиливается, він не покинутий. Також у нього були потрібні функцій «з коробки» (тулбар та інструменти для роботи з текстом — це те, що на GitHub) і можливості кастомізації.


Інструменти редагування з'являються тільки тоді, коли потрібні. За плюсик збоку ховається вставка фото і відео.

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

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


Виявивши вразливість, ми написали тим, хто використовує ME в проектах, і пояснили, як її закрити.

Уразливість виявилася при перших тестах. Ми зрозуміли, що в МЕНЕ немає захисту від небезпечних посилань, таких як:

javascript:alert('xss http://www.ru')

Це можна вирішити, елементарно відстежуючи і ламаючи послідовності виду javascript: як ми і зробили.

З одного боку, робимо грубо — у випадку з небезпечної посиланням, ми просто не намагаємося зберегти статтю. Але з іншого, якщо людина вирішить провести такий експеримент, то він явно не наш користувач.


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

Вирішено було запровадити знайомі нам по хакатону утиліти. Їх ми запхали в окремий микросервис у вигляді Docker-контейнера — своєрідний Python-wrapper зі своїм API, що працює через WSGI.



Одним з інструментів став „Друкар Муравйова“ . На мою скромну думку, у всьому Рунеті немає кращого інструменту для виправлення типографіки: значна зведення правил, реалізації на PHP і Python. І що дуже важливо — ліцензія.

До великої честі @emuragev, він поширюється як народне надбання (public domain), тому ми взяли його і прикрутили до нашого проекту в Python-реалізації. Поки нічого не міняли, хоча є можливість і ідеї, як доповнити правила».


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



Петро, наш розробник: «Концепція платформи — в цікавих історіях і оглядах без жорсткого регулювання тим і форматів. Але ще ми даємо заробити на кожному тексті. І зрозуміло, що він повинен бути унікальним.

В цілому, щоб реалізувати онлайн-функціонал для перевірки унікальності тексту, вам потрібна технологія Яндекс.XML і, в ідеалі, база текстових патернів, щоб спершу проганяти по ній текст, а вже потім звертатися до Y.XML.

Але кількість запитів з одного домену до сервісу Y.XML обмежена і залежить від тіц сайту. А який же тіц може бути у ще не релизнутого web-проекту? Жодної. А під час розробки постійно потрібно слати запити, парсити відповідь і щось робити з даними.



Можна було б, звичайно, надсилати запит з якого-небудь підвладного нам домену, де лежить сайт з великою тіц. Але в підсумку ми вирішили так не робити і взяти вже готовий API Content-Watch (CW). Система платна, але для нас хлопці пішли на спецумови.

Хоча відгуки в мережі різняться, здається, вони відмінно розібралися в питанні і запилили сервіс з хорошою документацією, мінімалістичним API і якими-то своїми алгоритмами в додаток до Y.XML.

Для нас, як для користувачів сервісу, все працює дуже просто — ми шолом запит на сервіс CW з текстом, який потрібно перевірити, а потім нам повертається відповідь у вигляді json. У відповіді міститься інформація про ступінь унікальності тексту (з нею ми показуємо красиву кругову діаграму) і посилання на сторінки у мережі, де зустрічається той чи інший фрагмент тексту — тему з посиланнями поки що використовують тільки модератори, які перевіряють статті перед публікацією на головній».


4. Як дати авторам аналізувати статті
Щоб авторам було цікавіше, ми вирішили впровадити інструменти аналізу тексту та оплату для всіх. Дохід утворюється так: поряд з текстом є два банера — рекламний та рекомендаційний. У банера є ціна кліка (її визначає рекламна система) — ми віддаємо 80% від вартості кожного кліка автору.

Ілля, CTO uPages: «Цікавою завданням було показати автору, скільки і коли він заробив, а заодно показати факт — статтю дочитають не все, і треба вчитися працювати над залученням всередині тексту, а не тільки над тизером і заголовком.

Тому ми зробили модуль статистики.



Він складається з клієнтської частини — ми малюємо графіки через Chart.js, віддаючи цифри і списки.

На стороні сервера ми вважаємо самі — кількість лайків, прочитань, закладок, наприклад.

А частина даних про кліках на банери, з яких і заробляє автор, — беремо через Google Analytics API і сервісу рекомендацій Engageya. Зручного API у других немає, але вдалося домовитися, що раз на добу вони вивантажують нам звіти з усією необхідною інформацією. Так ми показуємо кліки по рекламі збоку від статті та дохід автора.



У випадку з API Google, запити йдуть з певною періодичністю, щоб укластися в ліміти.
Так, Google API — це біль. При такій кількості різних продуктів припадає перечитати величезну кількість документації і спробувати кілька підходів. Спочатку ми намагалися використовувати AdSense Management API для отримання даних про дохід Adsense, але в їх звітах можна отримати інформацію для детального обліку джерел надходжень.

Після довгого гугления і биття головою об клавіатуру, порятунок прийшов від аналітики.
Між акаунтами Google Adsense і Analytics встановлюється зв'язок, після цього дані AdSense стають доступні при запитах до API аналітики».


5. Як це підтримувати

Руслан pys, системний адміністратор: «Завдання тонко натякала, що це повинен бути хмарний сервер. Ну і не дуже-то хотілося займатися всім цим моніторингом температури материнської плати, швидкості обертання вентиляторів, стежити за дисками — і міняти їх, не забуваючи переписувати серійники.

Вимоги до хмарних виртуалкам ми взяли наступні:

  • ЦОД в Москві (т. к. у нас російськомовна аудиторія),
  • зручне зміна конфігурації,
  • два сервера у різних провайдерів — для відмовостійкості і можливості проведення технічних робіт без даунтайма.


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

В якості системи деплоя контейнерів і управління конфігураціями ми вибрали Saltstack — оскільки вже успішно застосовували його на інших проектах.

За підсумками приведення сервісу в бойову готовність виникло закономірне бажання провести навчання, тобто стрільби з Яндекс.Танка. У ході експериментів з різним співвідношенням запитів до ядер процесора і параметрами системного та прикладного софту, ми визначили ємність однієї ноди і кореляцію цієї ємності з конфігурацією віртуального заліза та налаштування ОС. Ну і запустилися 1-го листопада».

p.s. Надсилайте свої http-запити на наш новий сервіс!
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.