Як робився новий дизайн сайту viva64.com розробників аналізатора коду PVS-Studio

10 років сайту viva64.com!

Сайту viva64.com — основний майданчику розробників аналізатора коду PVS-Studio виповнилося 10 років! Домен був зареєстрований 09.11.2006 року, а останнє серйозне оновлення дизайну було виконано в грудні 2010 року. Настав час щось змінити.



Учасники проекту
Зараз сайтом viva64.com займаються 4 людини:Інші люди займаються створенням контенту і не мають відношення до інфраструктури сайту, його зовнішнього вигляду і працездатності.

Що робить компанія
Ми робимо свій програмний продукт. Це інструмент для програмістів — аналізатор коду PVS-Studio. Він допомагає знайти помилки в програмах шляхом аналізу вихідного коду. Компанії-клієнти заощаджують гроші за рахунок раннього виявлення помилок до стадії бета-тестування і, тим більше, публічного випуску. Цей програмний продукт ми і продаємо.

Для просування аналізатора PVS-Studio ми пишемо статті про перевірку проектів з відкритим вихідним кодом, в яких знаходимо помилки за допомогою нашого інструменту.

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

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

З іншого боку, у нас є продукт для програмістів, але в епоху AppStore, Play Market та інших сторів, сайт окремого продукту не так-то вже цікавий кінцевим користувачам. Багато успішні продукти взагалі обходяться без сайту і нічого.

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

Об'єднавши все це в одну концепцію, ми прийшли до наступного. У нас контентний сайт. Проте з будь-якої його сторінки повинно бути зрозуміло, що є такий програмний продукт PVS-Studio.

Яку думку ми хочемо донести відвідувачу сайту?
Отже, у нас контентний проект. Але яку думку ми хочемо донести до тих, хто опинився у нас на сайті? Спочатку треба розібратися з тим, як відвідувачі потрапляють до нас на сайт і які сторінки користуються популярністю. Звернемося до Google Analytics. Ось огляд джерел трафіку за 10 місяців 2016 року (Acquisition Overview for Jan-Oct 2016):

<img src=«habrastorage.org/getpro/habr/post_images/bb4/19f/606/bb419f6064f95669b7d07f1b75c00153.png» alt=«Picture » 1"/>

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

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

Добре, з цим розібралися. Але як тоді «вести» відвідувача сайту до купівлі продукту? Адже, зрештою, всі статті пишуться заради цього.

Ми вважаємо, що наш цикл продажу складає близько трьох-шести місяців. За цей час людина повинна прочитати 3-4 статті про PVS-Studio і перевірити інструмент на своєму проекті. Далі, якщо нам пощастить, і інструмент людині сподобається, то він його купить.

Таким чином, наше завдання донести до відвідувача сайту відразу дві думки:
  • Треба прочитати 3-4 статті, а не піти після тієї, на яку він прийшов.
  • Треба авторитетно і з фактами переконати, що пропонований програмний продукт не пустушка, не шахрайство, а реально крута штука.
Для того, щоб чоловік прочитав 3-4 статті, треба показати йому, що ці статті є на сайті. Тому у нас є блок «Останні статті», який повинен потрапляти на очі.

Ми робимо величезну роботу — знаходимо помилки у проектах з вихідним кодом, і це допомагає людині повірити в інструмент. Завдання сайту зробити так, щоб відвідувач дізнався про перевірки. Тому у нас є блок «скільки ми перевірили проектів і скільки знайшли помилок». Перейшовши в цей розділ, користувач бачить повний список проектів, які ми коли-небудь перевіряли і всі знайдені помилки.

Перебуваючи на будь-якій сторінці сайту, відвідувач повинен розуміти, що є такий програмний продукт PVS-Studio і його можна на цьому сайті отримати. Тому в різних місцях «розкидані» згадки про аналізатор коду.

Які саме елементи розроблені для досягнення мети сайту
Ми визначилися, що мета сайту – поінформувати відвідувача, що на сайті є цікаві статті про перевірку проектів, і написані вони не без допомоги PVS-Studio. Який, у свою чергу, є об'єктивно гідним інструментом.

Як же конкретно цю думку ми доносимо? Поїхали по пунктах.

Шапка сайту
В шапці сайту написано, чим займається компанія («Ми робимо аналізатор коду»). З мого досвіду, часто сайт, у який вкладено багато грошей, не завжди відображає діяльність компанії. І добре, коли це багатопрофільні компанії на зразок Siemens або Samsung. Але часто навіть невеликі організації на 10-20 чоловік настільки захоплюються креативом, що сайт весь стрибає і переливається, але що компанія пропонує — незрозуміло.

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

Ліве меню сайту
Ліве меню сайту є супер мінімалістичним. У ньому містяться лише найважливіші пункти. Що на нашому сайті найважливіше? На нашу думку:
  • Блог, щоб завжди можна було почитати, «що новенького перевірили».
  • Список перевірених проектів і список знайдених у них помилок з конкретними числами, щоб люди бачили, що ми працюємо.
  • Поради з програмування.
  • Ну і, звичайно, наш програмний продукт.
Підвал сайту
Підвал досить простий:
  • Ще одне нагадування про PVS-Studio.
  • Список основних сторінок і розділів сайту.
  • Контакти.
  • Twitter, RSS.
  • Пошук по сайту.
Правий блок сайту (сайд-бар)
У правому блоці розмістилися такі традиційні елементи:
  • Останні статті.
  • Трансляція твіттера.
  • Список посилань «це цікаво».
З нетрадиційних елементів:
  • Блок «перевірених проектів» — з кількістю проектів і кількістю знайдених помилок.
  • Блок «приклади помилок» — реальні фрагменти коду з різних проектів.
Мета правого блоку полягає в тому, щоб читаючи статтю, відвідувач зрозумів, що на сайті є безліч інших цікавих матеріалів.

Для шанувальників продукту
Як у будь-якого продукту з історією, PVS-Studio є прихильники (і ненависники, але про них мені нічого сказати). Для цієї категорії людей ми підготували розділ з безкоштовною сувенірною продукцією.

<img src=«habrastorage.org/getpro/habr/post_images/a20/fd5/88f/a20fd588f1c9cc81b75b325a7e2ef440.png» alt=«Picture » 4"/>

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

Інтерв'ю з розробниками сайту
Стаття про розробку нової версії сайту була б неповною без коментарів з боку самих учасників процесу. Я попросив відповісти на кілька питань.

Сергій Харлеїв, веб-дизайнер
ЕР: Сергію, скажи, будь ласка, наскільки легко далася концепція сайту? Все-таки не магазин, не лендінгем, не просто блог. Як ти зрозумів, що ми робимо?

СХ: Так, проект виявився більше і складніше, ніж на перший погляд. Основна складність була в утриманні межі, не переборщувати з маркетингом. Але при цьому не забувати основне завдання сайту — продаж продукту. Цільова аудиторія у нас особлива, прискіплива, і не терпить нав'язливість. Тому ми всередині компанії створили імпровізовану фокус групу з програмістів і на ній відкочували деякі елементи і блоки сайту.

Для початку на перше місце ми поставили публікації, адже в першу чергу viva64.com це навчальний інформаційний ресурс. Тому основний наголос був на читабельність статей, і зручність користувачів. А сам аналізатор PVS-Studio пішов на другий план, переїхавши в підрозділ.

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

Але ми не забули про продукт, ненав'язливо згадуючи про нього, наприклад, з допомогою блоку «Перевірені проекти». В ньому ми розповідаємо, як аналізатор PVS-Studio свого часу знаходив серйозні помилки в коді у великих, відомих програмних продуктів, при цьому прикріплюючи конкретну помилку в коді. І на додачу демонстрували вагому статистику перевірених відкритих проектів, і знайдених у них помилок.

ЕР: Якими способами було вирішено повертати користувачів на сайті?

Взагалі у світі способів багато, але не кожен підходить для нашої аудиторії. Наприклад, ми не використовуємо e-mail підписку, так як наші користувачі м'яко кажучи, недолюблюють розсилки, також і соціальні мережі. Вибір припав на два канали, де у нас вже є передплатники, це twitter Андрія Карпова, і RSS.

ЕР: Наскільки сильно політ творчої думки піддавався цензурі?

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

ЕР: Скільки сторінок у підсумку довелося промалювати? Наскільки типово така кількість сторінок?

СГ: Більше 60 макетів, для кожної сторінки проектувалася планшетна і мобільна версія. Подібний підхід типовий для онлайн сервісів, але не часто використовується для корпоративних та інформаційних сайтів.

ЕР: Чим цей проект відрізнявся від інших твоїх проектів?

СХ: У мене вперше замовили бренд-бук для сайту, з правилами використання шрифтів, кольорів, відстаней, елементів і блоків. Це було одкровення, виявилося на рідкість зручний інструмент, і для розробників, і для самого себе, документ помітно прискорив і спростив процес.

Костянтин Потапов, веб-розробник
ЕР: Костянтин, перший запитання про терміни. В які часові рамки ти спочатку оцінював проект і скільки в підсумку вийшло? Як думаєш чому велика розбіжність?

КП: Спочатку я бачив лише простий елементарний сайт зі статтями. І оцінив створення сайту в більш сучасному дизайні в 3 тижні. Скільки вийшло я не в курсі, як кажуть «після релізу сайту його життя тільки починається».

ЕР: Ну я-то про терміни все знаю. Над дизайном з Сергієм ми почали працювати в середині травня 2016, закінчили (умовно, звичайно) в середині листопада, тобто півроку. Перші роботи над кодом сайту почалися в липні. Хоч можна сказати, що це до дизайну не мало стосунку, але це було потрібно для того, щоб з'явилося розуміння, що сайт «більше ніж здається». Безпосередньо новий дизайн почали верстати і кодувати в середині вересня, а реліз був у середині грудня. Тобто три місяці на ознайомлення з кодом та три — на основну роботу.

Ну так, майже три тижні і виходить… (Сарказм)

КП: Я не припускав, що у такого маленького сайту такі великі нутрощі. І це було як добре, так і погано. З хорошого там була крута система публікації статей на сайт. Матеріал люди готували в Word, спеціальним саморобним плагіном перетворювали це в набір .html спеціального виду, які можна публікувати як на основному, так і на інших сайтах. Крім того, там були інтеграції з додатком PVS-Studio, купа маркетингової аналітики.

З поганого там було багато «production-коду». Як я любив говорити своїм програмістам «це не production, тут не місце для милиць». Але зваживши всі за і проти і витративши пару тижнів на спробу вмістити всі яйця в одній корзині, а також значний час на причісування legacy-коду, прийшов до висновку про еволюційному підході. Судячи з усього, варіант «все взяти і переписати» для таких проектів вже не працює.

Окремої складністю був новий дизайн. Я звик працювати структурно, з жорстким сіток і над сенсом, а не емоційної подачею (благо не вмію гарно малювати). Я бачу багато недоліків, але як відомо «ідеальний продукт варто нескінченних грошей, нескінченно часу і не існує в природі». Тому довелося йти на компроміси.

ЕР: до Речі який розмір сайту зараз? Розмір контенту і розмір джерел.

КП: У момент написання цього тексту у нас є ось що:
  • Загальних статей (блог, новини, термінологія, уроки тощо) — 836;
  • Статей документації — 512 (як і належить програмістам);
Разом приблизно 1350 сторінок російською та англійською мовами. Крім того, є 255 (звідки ці программистские числа?) сторінок з прикладами помилок.

Коротше, виходить приблизно півтори тисячі статей російською та англійською.

Якщо говорити про код, то це 14 мегабайт коду не рахуючи бібліотек, але це трохи штучний показник. А для любителів статичного аналізу коду ось ще більш штучний на картинці.

<img src=«habrastorage.org/getpro/habr/post_images/bf3/8ff/701/bf38ff70135a962fcfebccea5df5229e.png» alt=«Picture » 2"/>

ЕР: Розкажи про «начинку» на якій працює сайт? Які технології використовувалися?

КП: Це сайт з багатою історією, який існує 10 років, робився різними програмістами. Напевно, слово «говнокод» вичистять при правці тексту, тому скажу так обтічно. З урахуванням цього, як відповідальна людина, я вирішив по мінімуму використовувати нестандартні або рідкісні технології щоб не було проблем з пошуком розробника, якщо мене зіб'є літак. Всередині стандартний Python 2.7, Django 1.9. Якщо б я починав проект з нуля, я б використав більш сучасні технології і, можливо, ще внедрю їх в процесі рефакторінгу. Але тут як з першої шлюбної ночі — ця честь до мене випала іншій людині 10 років тому :-).

ЕР: Про особливості верстки є що розповісти?

КП: Я намагався максимально впровадити «універсальну» верстку і зарізав (можливо даремно) готову верстку БЕМ-стилі (це коли кожен елемент верстається окремо). Цей підхід гарний для некерованих проектів з сотнею розробників і гарячими змінами. Але я прихильник того, що CSS — це каскадна таблиця стилів, і як мінімум намагався працювати в цій парадигмі. Також я намагався максимально використовувати можливості фреймворка (imposition framework), щоб просто приверстывать багато елементів, зовсім не залазячи в CSS. Але блін — це завжди компроміс. І я не впевнений, що моє рішення найкраще. Наприклад, зараз я хотів би переробити верстку через SASS і зробити її ще більш гнучкою. Коли я починав, не були вирішені багато композиційні питання, які спливають в процесі розробки. Крім того, я не до кінця втілив всі дизайнерські ідеї Сергія, але намагався зробити це по максимуму.

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

ЕР: Як був організований процес розробки? Гілки, різні сервера, все таке. Більше подробиць тільки!

КП:

У нас от яка інфраструктура зараз:
  • Бойової сервер — це зрозуміло.
  • Stage-сервер (для розробки) в режимі гарячого перемикання нового релізу і старого сайту для тіста змін.
  • «Сплячий сервер» (як ми його назвали) для резервного розгортання повної копії бойового.
На програмному рівні були впроваджені автоматизації і синхронізації між різними серверами. Схоже, це виправдалося на 200%. Можна оновити версію сайту «по повітрю» безпосередньо з системи адміністрування. Крім того, є ще окремий сервер на Jenkins, який автоматично конвертує .docx-статті в .html і заливає їх на сайт.

ЕР: Багато доводилося переробляти по кілька разів, і якщо так, то чому?

КП: Я дуже поважаю ефективність. І не розумію людей, які можуть сидіти і дивитися в монітор за дві години поспіль, чекаючи п'яти вечора або поки їх не підштовхне начальник. Цей сайт поставив переді мною архітектурний виклик з яким я раніше так щільно стикався лише одного разу, і я не вважаю, що зміг його вирішити в повній мірі. Я закінчив фізтех і у мене на підкірці прошита ідеологія учений-інженер-дослідник. Я створив десь 5 версій движка з різним переплетенням технологій і архітектур, але вперся в те що поміняти «все і відразу» занадто ризиковано. Пам'ятаю я як-то розробляв IP-телефонію для Таджикистану. Але у них там електрика тоді було по картках, не те що інтернет. І я, крім інших, зіткнувся з проблемою що їм потрібен саме G729 кодек (а не open-source 723). Ліцензією на який мали лише Intel і хтось ще. Але суть в тому, що із-за економії 5% трафіку я мало не заробив нервовий зрив.

Але в цьому проекті було кому зупинити мене вчасно від цих спроб перфекціонізму.

ЕР: Тепер, постфактум, яку б ти дав тимчасову оцінку для розробки нової версії дизайну сайту? А нової версії движка сайту?

КП: Три тижні на все. За умови, що не потрібна інтеграція з існуючою інфраструктурою, дизайн зберу я на готових компонентах і редагування статей через адмінку. А що? Це ж просто сайт зі статтями!!! Сподіваюся ви зрозуміли, що це сарказм.

ЕР: Які подальші кроки з сайтом необхідно зробити?

КП: Як мінімум, обов'язково потрібно наступне:
  • Асинхронно вантажити статику.
  • Повправлятися в магії з налаштуваннями сервера.
  • Поліпшити відображення сайту на різних пристроях.
  • Провести «навчальні тривоги» і перевірити, як функціонують резервні системи.
  • Задокументувати поточну систему (але в мене з цим проблеми).
  • Якщо зможу створити доки, хотів би піти у відпустку або померти з почуттям що «робота зроблена» :-).
Ілля Тетерін, інженер Linux
ЕР: Ілля, розкажи історію, завдяки якій ми познайомилися?

ІТ: Основний сайт відключили нібито за спам, та ще й почали заносити в чорні списки за нібито розповсюдження вірусів. Знадобилося терміново розбиратися, що відбувається, і це більше по моїй частині. В юності був у хакерській тусовці, деякі навички залишилися. Втім, виявилося, що ніякі злісні диверсанти не діяли, а всього лише недостатньо добре організована захист від звичайних вірусів, що крадуть паролі від FTP. Офіс-то захистили нормально, а от на домашніх комп'ютерах, де теж буває службова інформація, всі дыряво. Втім, складно в цьому дорікати рядову софтовую фірму, коли на аналогічні граблі нарвалися навіть кандидати в президенти США і їхні команди. Зараз, думаю, ситуація значно покращилася, від небезпечних протоколів позбулися, права всім порізали, зробили навіювання співробітникам і т. д.

ЕР: Так, а розкажи про залізо, на якому працює сайт.

ІТ: Для даного сайту не потрібно якихось екстраординарних обчислювальних потужностей, але потрібна стабільна робота. Використовується віртуальний виділений сервер, він забезпечує гарний резерв по міцності. У випадку, якщо щось піде не так (зростання відвідуваності на порядки, DDoS-атаки) — ми готові в найкоротші терміни мігрувати на більш потужний сервер або навіть організувати кластер, а також підключити зовнішні сервіси захисту, щоб забезпечити безперебійну роботу сайту.

ЕР: Які завдання по організації роботи сервера були вирішені, а що ще тільки належить зробити у найближчому майбутньому?

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

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

Крім того, варто створити скрипт для автоматичного розгортання готової системи з образу на будь-якому сервері (щоб це робилося за хвилини, а не за десятки хвилин).

ЕР: Вже хочу це все!

Висновок
Ми добре попрацювали над новим сайтом, але не вважаємо свою роботу закінченою. Тому будемо раді отримати ваші зауваження, побажання щодо поліпшення коментарі і просто про нову версію сайту www.viva64.com.



Якщо хочете поділитися цією статтею з англомовної аудиторією, то прошу використовувати посилання на переклад: Yevhen Ryzhkov. The new design of viva64.com. The story behind it, told by the PVS-Studio developers
Джерело: Хабрахабр

0 коментарів

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