Веб-разработка

Расскажу про свой факап. Сейчас за него не сколько стыдно, сколько смешно.

Работаю админом в одном маленьком офисе с большими амбициями. Как полагается для такой конторы, тут у нас холдинг и куча ООО-ЗАО-ИП (10 организаций, если быть точным) и практически для каждой есть свой сайт, а для некоторых даже не один. Когда я пришёл к ним, большая часть сайтов была уже сделана и благополучно забыта, но парочку всё-таки пришлось рисовать мне. За «спасибо» и символическую премию. Я не против, это для меня было что-то новое и интересное. Собрали один такой сайт-информационку на джумле из пиратских модулей (с порно-ссылками, которые потом долго выслеживали и вычищали), нарисовали всё красиво (то есть руководитель сказал «ок»), а всё, что было некрасиво — скрыли.

В один прекрасный день ко мне подошла наша сотрудница, которая помимо торговли с Китаем добровольно-принудительно работала контентщицей на этом сайте, и ткнула меня носом в одну статью, где куча ботов наспамила комментов. Особо не разбираясь, поле комментов и их ввода мы просто скрыли через visibility: hidden (так как они там вообще не нужны), и всё снова стало красиво.

Прошло полгода. Месяц назад от хостера мне посыпались письма с угрозами: «Место на хостинге кончается, купите больше хостинга или мы вас закроем». Добавил сотню метров. Через пару недель опять то же самое. Добавил ещё сотню. На третьей сотне мне уже стало любопытно — что же так раздувает наш хостинг? Не новый ли сайт на OC Store с интеграцией в 1С и ежедневной выгрузкой номенклатуры? Полез через PhpMyAdmin смотреть размеры таблиц. И тут-то я и увидел то, что на весь остаток дня заставило меня улыбаться. Так как спираченный шаблон на джумлу победить до конца не удалось, недостающий функционал заменили на К2 и локализовали вручную (сам переводил, да). И таблица %prefix%_k2_comments была раздута до 1,5 Гб с содержимым в > 2 млн. строк. Судя по содержимому, боты, однажды зацепившись за пару статей, продолжали спамить туда свои китайские ссылки на протяжении всех этих долгих месяцев.

DELETE FROM %prefix%_k2_comments WHERE id > 1

И сразу размер базы уменьшился до 6 Мб. И стыдно, и смешно.

Мораль сей басни такова: если накрыть кучку тряпочкой — это вовсе не значит, что она не будет вонять.

Занимались не так давно внедрением интернет-магазина для торговой компании. Стояла задача подготовить счёт, который выставляется юридическим лицам. Все мы знаем, что в любом счёте внизу обычно размещаются подписи директора и бухгалтера, а также печать организации. Естественно, я запросила их у заказчика, мол, просим предоставить образцы печати и подписи для оформления счёта интернет-магазина. Заказчик мне ответила, что пока «живые» печать и подпись вам не нужны, справляйтесь без них.

Не вопрос, справились. Взяли первую попавшуюся подходящую демо-печать с прозрачным фоном. Далеко ходить не нужно, всё нашлось в картинках одного из поисковиков. Ну и попутно подготовили себе в запасничек демо-подписи «Гендиректор» и «Главбух», выведенные красивым рукописным шрифтом. Всё настроили и забыли до получения оригиналов. На следующий день нам приходит грозное письмо от разъярённого клиента:

Добрый день!

Прошу вас остановить работу по сайту. После вчерашней шутки в общем доступе на сайте (подпись и печать «Рога и копыта») я хочу прекратить наши деловые отношения.

Естественно, мы принесли заказчику извинения:

Здравствуйте, ООО ***.

Для тестирования интернет-магазина необходимо заполнение ключевых элементов счёта. Так как запрошенную информацию мы от вас не получили, а работы необходимо было провести, то соответствующие элементы счёта были заменены демонстрационными данными абстрактной компании. Наши действия не являлись какой-либо шуткой или провокацией. Приносим свои извинения, если вы сочли их некорректными.

Мораль сей басни очевидна: нужно быть внимательнее при выборе демо-материалов, чтобы не травмировать чувствительную психику клиента. Ибо для нас, разработчиков, это просто сайт с демо-контентом, а для владелеца — дело всей жизни, и он вполне может принять за личное оскорбление безобидные картинки.

Иногда я пилю сайты. Вообще, в последнее время я делаю это всё чаще. На моей практике уже почти семнадцать собственноручно выполненных проектов. Вы знаете, сколько из них я мог бы продемонстрировать в своём портфолио, если бы это было нужно? Два. Что не так с остальными? Правки.

Моим первым заданием, после которого я не отчаялся и захотел освоить это ремесло, был сайт о путешествиях, который нужно было «поправить». Простая визиточка плюс информация о ключевых странах. Что же мне пришлось «править»?

Сначала они хотели «3D глобус, чтобы вращался мышкой, а на нём выбираешь на страну — и тебя перекидывает на страницу с информацией о ней и фоточками». Узнав цену на это дело, заказчик передумал. Захотел всего лишь сине-желтую гамму (чистые цвета, как попугай ара). Потом добавили кучу виджетов авиалиний, поездов, погоды и прочего. Потом — фоновую песню «Nosa, nosa». Я не признаюсь, что это моих рук дело, даже под пытками.

Затем был один из городских ресторанов. Но они отказались фотографировать блюда отдельно — настаивали исключительно на шакальном скане меню. И чтобы на каждой странице шторочки раздвигались. Ладно хоть без музыки.

Была местная консалтинговая контора. Их устраивал онли дизайн «web 1.0», если вы понимаете, о чём я.

Сайт риэлтора хотел, чтобы всё на странице сверкало, блестело, свистело и далее по списку. Знаете, как в старых играх — персонаж не может стоять спокойно в ожидании. Он словно под веществами.

Цветочный магазин хотел поиск по сайту. Но не тот, что корректно работает по артикулу и наименованию, а тот, что сперва выдает кучу продвигаемых товаров, пусть и не соответствующих запросу.

Мне пришлось и с дизайнерами поработать. Знаете, у нас в городе нет дизайнеров, которые работают с вебом. Я предупреждаю об этом. Но «да не, он крутой, он нам офигенные буклеты сбацал». Ладно, кто платит — тот танцует.

Один сделал сайт, похожий на рекламный буклет или меню суши-бара. Знаете, светлый фон из паттернов с мелкими суши-ролло-палочко-мисочко-бутылками, кремовые цвета, красные акценты… Всю информацию попытались вместить в экран 1024x768. Получилась теснота, хаос и неразбериха. Как ни странно, именно его я теперь могу показать, не стыдясь — до владельца дошли мои увещевания и демонстрация стильных, аккуратных сайтов в этом бизнесе. Мы сделали адаптивный дизайн, крупные карточки товаров, хорошие фото и прочее. Вышло неплохо.

Теперь есть сайт магазина аксессуаров. Его я сдал ещё месяц назад. Но они взяли дизайнера. Был довольно лаконичный дизайн в стиле современных мобильных приложений типа viber или хотя бы gmail. Строгий фон, цветовые акценты в нужных местах, ничто не отвлекает от главного — красивых фото товаров. Сказали мне, что «да-да, мы ж всё согласовали, ничего не поменяется радикально, просто цвета-шрифты-логотип да пара свежих баннеров». Ок, это вполне входит в стоимость, мне ничего не надо сверху.

Знаете, что я вижу вчера в макете? Совершенно другое меню (от полностью раскрытого вертикального к разворачивающемуся двухуровневому горизонтальному), переколбашенные функциональные блоки, фон из красной змеиной кожи, фон подвала и кнопок меню из золотой змеиной кожи, вообще всё бордово-золотое. Выглядит даже не как современная полиграфия — как «бохатая» цыганская полиграфия старых времен.

Мне плевать, что опять выйдет то, что стыдно показать. Мне не плевать, что опять придётся доказывать, что уговор про «ноль рублей, если только шрифты-цвета-сменить картинку» — это не про то, что тут наколбасилось.

Знаете что? Я хочу чинить чайники в отделе гарантийного ремонта в каком-нибудь «Дорадо» или «Видео».

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

В первую очередь возрадуйтесь блеснувшим вдали золотым горам и ни в коем случае не читайте техническое задание. Не читайте его, когда заказчик предлагает вам составить график работ. Просто прикиньте, сколько времени потребуется на мало-мальскую переделку чего-нибудь уже готового, и поклянитесь, что сделаете всё-всё в полтора раза быстрее, чем прогнозировал заказчик.

Непременно исключите все этапы согласования с заказчиком промежуточных результатов работ и потенциально спорных моментов. Укажите, что сделаете за один день любой программный модуль, даже если имеете об этом лишь общие понятия в стиле «где-то слышал». Поверьте, заказчик будет счастлив, что вы так быстры (а вдруг и вправду у вас Супермен в команде), и подписание контракта вам обеспечено.

Когда подписанный контракт у вас в руках и кругленькая сумма приятно замаячила на горизонте, ни в коем случае не читайте техническое задание. Выведите из пятилетнего анабиотического сна того, кого называете дизайнером, и посадите его за работу. Все же знают, что за последние пять лет в дизайне сайтов ничего не изменилось.

Заказчик показал вам нечто древнее и страшное. Говорит, что сайт, заказанный у вас, предназначен для того, чтобы этот антиквариат заменить. Прекрасно — вы же можете оттуда скопировать все пункты меню. Покажите этот тлен веков своему дизайнеру, но никогда, ни при каких условиях не показывайте ему техническое задание! В конце концов, у вас же есть свой, проверенный годами шаблон, который вы уже продали целых пятнадцать раз. Перекрасьте его, поменяйте пункты меню. Будьте уверены: заказчик точно будет счастлив!

Упс. Заказчик не счастлив. Не верьте и не сдавайтесь! Нарисуйте ещё один скин своего любимого шаблона, но не читайте техническое задание.

Две трети времени, предусмотренного подписанным вами графиком, уже прошло, а ваш дизайн так и не принят? Заказчик говорит, что закажет дизайн у других и пришлёт вам? Ну и фиг с ним, раз такой дурак. Вам ведь не впервой «натягивать» чужие макеты. Забейте.

Заказчик говорит, что в техническом задании есть работа с админкой, с личным кабинетом, которую можно делать до утверждения дизайна? Не верьте ему. Будьте тверды. Скажите, что не будете ничего делать, пока не будет утверждённого дизайна.

Наконец вам прислали дизайн. Ваши верстальщики в обмороке. Вы такое никогда не делали. Не вздумайте с перепугу прочитать техническое задание! Возьмитесь за фотошоп. Нафотошопьте гибрид хотелок заказчика и своего любимого шаблона. Это будут ваши эскизы. Они не нравятся заказчику, потому что вы половину его хотелок выбросили, а остальное выглядит уродливо? Ну и ладно. В конце концов, вам тоже не нравится то, что заказчик прислал.

Когда пройдёт ещё две трети первоначального срока выполнения работ, и вы, и заказчик будете уже достаточно замучены, чтобы наконец-то согласовать дизайн. Результат будет противен обоим, но цель достигнута: вы переходите на следующий уровень.

Пообещайте заказчику, что всё остальное доделаете за неделю. Убедитесь, что, обещая, вы не прочли технического задания.

Возьмите какой-нибудь из своих старых проектов и натяните на него дизайн. Утверждайте, что вы совсем чуть-чуть не успели. Увереннее доказывайте усомнившемуся заказчику, что это именно то, чего он хотел.

Если заказчик грозится расторгнуть договор и просит предоставить документацию, отвечайте как можно лаконичнее: «сделано», «сделано частично», «не сделано». Пусть вас не смущает, что сделанным вы объявили то, что является связующим звеном между двумя не сделанными частями. Только не читайте техническое задание.

Когда время очередных доделок истекло, устройте торжественный показ. Максимум уверенности: «Тут играем, тут не играем, здесь жирное пятно — рыбу заворачивали».

Если по непонятной причине ваш доклад не произвёл должного впечатления, а заказчик постоянно упоминает какое-то техническое задание, прочтите наконец злосчастный документ.

Попросите вас отпустить.

Я веб-разработчик. Прислали ТЗ:

В каталог товаров добавить боковой фильтр по следующим критериям:

• По цене (от и до)

• По цвету

• По полу (мужчины, женщины, дети)

Настроение — на целый день.

— С чем у вас ассоциируется этот значок? — спросил журналист и показал синюю букву e с кружком.

— С геморроем, матом, мамонтами, желанием убивать и бессонными ночами, — ответил я.

— Но… почему?

— Я занимаюсь веб-разработкой.

Оказалось, что у большинства среднестатистического населения злосчастная буква ассоциируется с запрещёнными у нас и маскирующимися под интернет-клубы подпольными казино. Зло многогранно, но символ его — один.

Коллеги! Выбирайте технологии. Выбирайте так, чтобы потом не жаловаться, что приходится поддерживать за кем-то код «не очень красивого цвета», который ещё и пахнет соответственно.

Поделюсь немного своим опытом. Я веб-разработчик, программист, в основном бэкэнд.

До относительно недавних пор я работал преимущественно с широко известной в России CMS, отличающейся агрессивным маркетингом (вплоть до упоминания жёлтой программы в своём названии), низким порогом вхождения и широкими возможностями нарушения архитектуры. Точно так же, как и многие любители чистого и красивого кода, плакал кровью, глядя на некоторые конструкции, особенно написанные «золотыми сертифицированными партнёрами», осилившими эпический труд «PHP за 24 часа для чайников». Компонент (почти аналог контроллера в традиционных системах), который не содержит логики, а только подключает тот или иной шаблон в зависимости от входного параметра — нормально! А вся логика в шаблоне. Вплоть до обращения к БД. Да, прямыми SQL-запросами, несмотря на то, что система имеет хоть и своеобразный, но всё же ORM. А что? В учебниках для начинающих же действительно есть такие примеры, и возможность обратиться в БД прямо из HTML-файла преподносится как преимущество и неоспоримое достоинство PHP. Но ладно. Сами авторы системы тоже не ангелы. Кто-то про классы жаловался? Так вот, классы — это, по мнению авторов замечательной (без иронии) CMS, всего лишь способ логически объединить несколько функций. Большинство методов класса статические. Но в некоторых случаях нужно создавать объект класса, который будет использован только для вызова одного метода, и нигде и никогда больше. Такое своеобразное видение ООП.

Беда? Однозначно беда. Копаться в таком быдлокоде — приятного мало. Надо было что-то делать. Я изучил альтернативы и остановился на приятном фреймворке Django, с помощью которого теперь и разрабатываю сайты. Возможно, вы не поверите, но проблема чужого кода исчезла. Во-первых, оформление кода. Оно всегда и у всех одинаковое. Синтаксис языка Python предъявляет жёсткие требования. Питоновская идеология также гласит, что для решения задачи должен быть один очевидный способ. В Django эта идея поддерживается. И это помогает, экономит время и нервы. Кто бы ни писал до меня, я заранее знаю, где искать нужный код, даже если проект впервые вижу.

Порог вхождения намного выше. То есть нельзя, просмотрев один 15-минутный видеоурок, сразу начать клепать «визиточки». Нужно иметь некоторую базовую подготовку и потратить время на изучение. Это отсекает случайных людей: средний уровень разработчика на Django намного выше, чем средний уровень широко рекламируемых решений с низким порогом вхождения. А значит, и качество кода выше.

И ещё один бонус, который не сразу очевиден: повышается качество заказчиков. Довольно легко убедить в преимуществах своего предложения заказчика, которому важен результат, нацеленного на долгосрочное сотрудничество. И практически невозможно склонить на свою сторону тех, чья главная цель — снять с себя ответственность: всяких менеджеров по просиживанию штанов.

В общем, я для себя нашёл инструмент, который помогает работать эффективно и с удовольствием, а не страдать от кривых решений. Ищите и вы. Пробуйте, изучайте. Хороших инструментов много. Спрос на качественную работу есть. А кому надо подешевле, и чтобы легко найти какого-нибудь неудачника нам на замену, те пусть жуют свой кактус сами: не в наших интересах таких поддерживать.

Когда-то давно был популярен такой анекдот: «В то время как обычный пользователь полагает, будто в килобайте тысяча байт, программист точно знает, что в километре 1024 метра».

Вспомнил я его, наблюдая за действиями одного из наших программистов. Ему потребовалось узнать количество символов в фразе при заполнении документа. Многие знают, что в Ворде узнать количество символов достаточно просто. Но Ворд не является основным рабочим инструментом веб-программиста, и проще ему оказалось открыть веб-инспектор в Хроме и вписать нечто вроде 'интересующая фраза'.length.

Яваскрипт, конечно же, всё посчитал. Я добавил этот способ в копилку.

Дело было в студенческие годы на инязе. Для облегчения жизни студентов и преподавателей инженер-программист внедрил новшество в виде сайта факультета с регистрацией студентов и тестами вместо привычных диктантов. Суть такова: студент, получив номер тестового задания, видит текст с определённым количеством ошибок. Задача — исправить их. Если поставить лишний пробел, машина воспринимало каждый символ после него как ошибку: посимвольное сравнение с оригиналом и прочие чексуммы.

Вместо того чтобы готовиться к диктанту, я, чуток умевший пользоваться HTML, пошёл на хитрость: пригласив молодую симпатичную препода, я попросил проверить мою статистику (нужно было войти под училковским паролем). Мило заговаривая ей зубы во время ввода заветных символов, я, конечно же, их подсмотрел. Имея запас правильных вариантов текстов, я написал простенькую формочку (скопировал исходный код с правильной ссылкой, ага), отправлявшую этот вариант на сервер для анализа и выставления оценки. Для удобства сделал выпадающий список с номерами тестовых заданий, а хранил творение на флопике (дело было очень давно).

К слову, часть сети была под моим контролем с помощью Радмина, потому я мог удалённо помогать одногруппникам, что с удовольствием делал, чем вызвал бурю эмоций у отличниц, готовившихся всю ночь и получивших случайный тройбан, хотя я им тоже предлагал помощь.

Я допустил оплошность. Разница между двумя идеально «пройденными» тестами составила пару секунд, после чего, как я узнал на выпускном, за мной велась удалённая слежка.

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

Солнце в бутылке, говорите? Ну-ну…

Во-первых, во время дождей оно будет протекать. Надежный герметик будет дороже, чем вырезать в стене окно. А дождей в нашем климате вполне достаточно.

Во-вторых, в нашем климате зимой идёт снег. Небольшой его слой на крыше — и привет «солнцу», от простого затемнения до выпадения бутылки вниз из-за весовой нагрузки.

Всё это знаете что мне напоминает? Новичок узнал новую-новую технологию — и давай её повсеместно внедрять.

Вышла новая версия ОС? Надо поставить её везде. А потом начинаются пляски с бубнами: как её убедить не тормозить на старом железе и заставить заработать тот софт, что на этом компе используется для основной рабочей деятельности.

Вышел новый фреймворк? А давайте его запилим в наш сайтик! Это же круто — быть на острие технологий. А то что, для этого сайтика вполне хватит обычного статического HTML с CGI на голом PHP — это неважно. Главное — чтобы мы были на острие прогресса. Клиенты начинают жаловаться: «А чего у нас страничка с тремя кнопками и одним выпадающим списком тормозит?»

Хотите внедрять новое? Хорошо. Но только проверьте, не выйдет ли это хуже и дороже, а уже потом пойте на весь свет, как это круто, желательно с указанием, где вы это удачно применили.

Ладно бы маркетолог — ему за это платят. Но технарь, заболевший «New New Stimorol»… Такому хочется взять и настучать томиком Кнута или Кагана по голове.

И да, серьёзные исследования этого «чудо-изобретения» показывают, что световой поток от него — с гулькин нос. Подобный световой канал с зеркалами-линзами актуален в подземелье. Но в обычных хижинах уже много десятков тысяч лет все нормальные люди делают окна.

В развивающихся странах не редкость домики без окон. Ставить их долго, дорого, а иногда домик заставлен со всех сторон соседними — прорубать окно бесполезно, будет загорожено. Жителям таких строений приходится пользоваться автономными источниками искусственного света даже днём.

Но эти постройки одноэтажные, поэтому крыша днём освещена. Гениальнейший девайс под названием solar bottle bulb устанавливается быстрее окна, стоит дешевле, ярко освещает помещение, когда светит солнце. Такой вот упрощённый наколенный вариант более сложных конструкций — skylight и light tube. Кстати, в электрифицированной местности бутылочную лампу тоже есть где внедрять — если лень, например, тащить проводку в хозблок. Ну, в наших условиях придётся солёную воду применить, чтобы зимой не замерзала. Да и в туристической палатке такой светильник не помешает. А ещё ему не страшны мальчишки с мячом.

Выводы:

1. Окна — долго, дорого, для их установки не всегда достаточно ресурсов, их могут разбить.

2. Кто ими не избалован, у того наиболее безболезненно проходит внедрение LAMP.

Занимаюсь поддержкой и доработкой модуля CRM биллинговой системы. По функциональности очень жирный модуль: около 200 визуальных форм, по сути, одно из основных рабочих мест биллинговой системы.

Разработка начиналась около 15 лет назад на средстве разработки, столь популярном тогда на территории экс-СССР, названном в честь древнегреческого города. Тогда это был передовой край IT — визуальное средство позволяло быстро и качественно рисовать пользовательский интерфейс. А архитектура этого средства позволяла дорабатывать стандартные компоненты и классы, разрабатывать свои собственные или использовать сторонние, что повышало качество и привлекательность создаваемого программного продукта.

В отличии от маститых конкурентов, имевших тяжкий груз наследия старого кода, разрабатывали уже трёхзвенную архитектуру, чем немало гордились. Вот, мол, у них надо драйвера базы ставить (драйвера Оracle поставить и настроить — это довольно муторно, если рабочих мест за сотню с лишним), кому-то ещё фреймворк для работы клиента, а у нас тонкий клиент: создал ярлык на экзешник с файл-сервера, и уже всё работает. Конкуренты апеллировали, что клиентские места надо создавать в средствах разработки, которые заточены для работы с БД и прям со структуры базы сами рисуют пользовательский интерфейс (страшный и кривой, зато возиться не надо), а не на вашем комбайне, на котором только утилитки десктопные строгать.

Прошло пяток лет, и тонким клиентом стал считаться веб-браузер. В те годы они, конечно, мало что умели и годились для ввода пары строчек в простейшей форме редактирования или отображения не слишком большой таблицы (какие сортировки/фильтрации/группировки — забудьте!). Конкуренты, вышедшие на рынок после нас, потешались над нами за отсталость технологий, мы над ними — за убогость интерфейса.

И вот развитие веб-технологий позволяет нарисовать интерфейс, неотличимый от нативного, а средства разработки позволяют нарисовать его комфортно. Вот только браузер с открытой почтой, новостным сайтом и этой страничкой ест оперативы столько же, сколько сервер приложений с полутысячей активных пользователей, и в пять раз больше клиента, в котором загружен список под сотню тысяч записей (раз клиент хочет себя мучить такими списками, то проще сделать, чем спорить).

Да, у нас разрабатываются небольшие специализированные рабочие места на веб-технологиях (зачастую с бо́льшими трудозатратами, чем потребовались бы для реализации того же на древнем, но удобном средстве разработки), но переписывать огромный продукт, понимая при этом, что это не только потребует совсем других ресурсов и от сервера приложений, и от клиентских мест, но ещё и ограничит функциональность… Мы это время лучше потратим на развитие системы, а я своё свободное рабочее время — на изучение фич новой версии БД, название которой некоторым образом ассоциируется с описанной средой разработки. Всё-таки основная моя специализация — разработка БД.

К чему это я? Да все к тому же баяну, повторяемому тут на каждой странице: холивар вечен и повторяется на каждом витке развития технологий. А каждой технологии своё место и своё применение.

Смотрю я на диалог «старых» ООП-разработчиков и новых «хипстеров» насчёт отрисовки на стороне клиента и вспоминаю конец девяностых — начало нулевых. Я тогда фрилансил, и новомодные задачи типа отрисовки всей странички на клиенте, передав лишь данные, были в порядке вещей. Данные передавались через невидимый фрейм. Задачи были простые и понятные: те же новостные ленты, магазины, форумы, аукционы и прочая дребедень. Всё это отлично работало на средненьком железе того времени. Потом появилось следующее поколение разработчиков — ну, вы понимаете, максимальный упор на ООП, SQL, медленные интерпретаторы, — и внезапно оказалось, что те же самые задачи уже решаются целыми коллективами за втрое большее время и требуют многократно больших вычислительных мощностей.

Думаете, на этом ситуация прекратила ухудшаться? Ха! Появился сперва XML, удачно сочетающий тормознутость текстового формата с нечитаемостью машинного, и вместе с ним мода на передачу любых данных с помощью XML. Можно ли сделать ещё хуже? Можно! На сцену вышел XSLT, и всё стало ещё в три раза медленнее и в пять раз забагованнее (ибо валидация). У меня перед глазами был пример, как команда из пяти разработчиков полтора года ваяла самый обычный форум. При этом у них всё время кипела работа, они героически боролись с легионами багов, они переписывали кучу кода из-за «новых требований, несовместимых с архитектурой». Разобраться в этом кошмаре после них не смог никто.

Новые технологии могут облегчать процесс разработки. Делать его проще, понятнее, логичнее. Но, как и все инструменты, они хороши лишь в руках мастера. Простота их использования притянула в IT множество мути с самого дна интеллектуальной бездны. Эти эмуляторы программистов отлично владеют терминологией и часто её употребляют, но вот когда доходит до дела… Ну, вы поняли.

Во время кризиса, когда всё было плохо и не было работы, устроился я в одну контору. Владельцы, поднявшись на торговле постельным бельём, решили основать «фирму, что сайты делает».

На момент моего прихода картина была такой:

• три менеджера обзванивают потенциальных клиентов;

• один дизайнер рисует внешний вид;

• я, как внешний вид утверждён, делаю шкурку к Джумле или Вордпрессу;

• любую функциональность, выходящую за рамки стандартной, делают за дополнительную плату знакомые РНР-программисты.

Для менеджеров в своё время были написаны инструкции: что входит в стандартные услуги и что не входит. Для всех стандартных услуг чётко прописаны цены и сроки. Стоит ли упоминать о том, что менеджеры в инструкции даже не заглядывали и самым частым ответом было: «Я сейчас дам трубку специалисту, он вам расскажет»?

Другие изречения менеджеров, хоть и встречались реже, тоже достойны внимания:

— Нет, мы не делаем интернет-странички. Только сайты, интернет-магазины и корпоративные сайты.

— Конечно, в стоимость входит интеграция с 1С. (На самом деле её нет в стандартной поставке.)

— Да, вы можете сами нарисовать дизайн, а я дам вам скидку на стоимость дизайна. (А повышать цену на возросшую трудоёмкость вёрстки?)

— Да, конечно, за две недели будет. (Только эти две недели где-то после Нового года, когда закончим предыдущее.)

Со временем ад рос и ширился. Менеджеры спихивали с себя всю работу, которую только можно спихнуть:

• переписку с клиентами: «Ой, они спрашивают про дополнительную функциональность, я там ничего не понимаю». На самом деле ответы на вопросы есть в инструкции и функциональность вовсе не дополнительная;

• наполнение сайта фирмы новостями: «Я добавляю текст, а он не добавляется. Вот файлик, попробуйте, может у вас получится». Плавно трансформировалось в «Вы уже написали про запуск нового сайта?»;

• ответы на тендеры: «А вы можете им ответить, а то я не знаю, того ли они хотят?»

Это без учёта того, что менеджеры порывались запихнуть в стандартную цену дополнительные плюшки, а разруливать приходилось нам.

Особо отличилась тут девочка с декольте +5 к убеждению. Оно слабо действовало на нас, но безотказно на владельца. Очень быстро она стала старшим менеджером, потом начальником отдела менеджмента (количество людей не изменилось). Когда владельцы поехали в отпуск, её на два месяца сделали исполняющей обязанности директора.

Последнее назначение ударило ей в голову, и она узаконила всё то, что делала раньше. На меня и дизайнера упала полностью переписка с клиентами и все переговоры, выходящие за рамки «Здравствуйте, вам нужен сайт?». К тому же мы стали должны следить за тендерами, вовремя на них отвечать и стараться бесплатно сделать дополнительную функциональность, если её случайно утвердили менеджеры.

Закончилось всё довольно печально: трудности с увольнением и отработкой, плюс «серая» часть зарплаты к нам так и не попала. Но, едва всё завершилось, в мой почтовый ящик упали четыре письма от старых клиентов — им понадобились сайты, и они машинально обратились к тому, с кем привыкли вести переговоры.

Я из тех новомодных хипстеров, что разбрасываются словами «инверсия управления», REST, «клиентская шаблонизация», MVVM и прочие Events Observer и Shadow DOM. Мы знаем и применяем эти страшные слова не потому, что хотим погнуть пальцы перед другими кодерами и инвесторами. Инвесторам зачастую вообще всё равно, на чём будет написан продукт, хоть на С++, а от слова «облако» у многих уже начинается нервный тик.

Прошли те времена, когда страница веб-сайта (или его админки) представляла собой отдельную сущность, управляющую одной-двумя связанными с ней моделями для БД через слой контроллера. Сейчас фронт веб-приложения рендерит огромное число данных, самыми невообразимыми путями связанными друг с другом, и изменение данных внутри одного виджета должно повлиять на перерисовку половины элементов страницы.

Я видел боль сторонников традиционных решений, когда их просят вставить маленький выпадающий список в админку: они берут уже готовые куски кода из контроллеров, которые задают эту сущность, копипастят в новый, что-то правят, что-то костыляют — и в результате данные, которые вообще не должны по принципам SOLID попадать в класс, в нём извлекаются.

Мне же на Ангуляре достаточно создать шаблон (или директиву) и инжектировать в контроллер ещё один сервис, потому что API для управления данных для этого маленького виджета выпадающего списка уже есть, ибо нужный список используется уже во многих местах системы. Час на разработку, час на создание автотестов — и новая нужная пользователям функция готова.

Тут должен быть рассказ про то, как я делал вёрстку в стиле HTML 4.0 для старых мобильных девайсов, но оставлю это для третьего участника, который традиционно примирит обе стороны.

Всем добра!

Новомодные решения в плане «передавать не вёрстку, а данные» чаще всего делаются только ради того, чтоб «выглядеть модно и современно». В основном перед заказчиком или инвестором.

Есть старый критерий: стабильность системы обратно пропорциональна количеству взаимодействующих между собой объектов. Если перекладывать часть функциональности на сторону клиента, то ни в чём нельзя быть уверенным.

Я работаю в сфере веб-разработки больше 10 лет, и за всё это время был лишь один случай, когда по объективным причинам понадобилась надстройка (JS + некоторое не особо сильное колдунство на серверной стороне) для того, чтобы клиент и сервер перекидывались данными только в виде JSON после загрузки первой страницы, где передавался HTML. Причина — флеш-плеер, который должен воспроизводить музыку без заиканий.

Профессионализм в сфере вебдева заключается не в том, чтоб оно «выглядело современно», а, скорее, в том, чтоб оно хоть как-то выглядело на любой клиентской железке, будь то PC, Mac, планшет под «окнами», «зелёным роботом», iOS или какой-то экзотикой. И не только выглядело, но и сохраняло свою функциональность в полном объёме.

Нет, я не являюсь каким-то ретардиозным луддитом. Я, как и все, слежу за новостями в отрасли и пытаюсь освоить всё новое. Но это не значит, что я буду сразу применять всё это на практике.

Когда-то начальство спросило, возможно ли интегрировать нашу платёжную систему в Smart TV. Вбил в Гугл новое для меня слово, почитал доки и с уверенностью сказал, что технических преград нет. Желаю подобной уверенности и вам, коллеги.

Сегодня резко ухудшилось самочувствие: стошнило, поднялась температура до сорока, заболело горло. Полный набор для выдачи больничного. Так уж вышло, что денег на мобильном не оказалось, а «обещанный платёж» уже был израсходован.

Но ничего, ведь у меня же есть онлайн-кошелёк! И там много-много денег, которые я смогу перекинуть на телефон, чтобы сделать один звонок. Но живу я в глухомани, сижу с Йотовского модема, который плохо ловит покрытие и не может прогрузить все эти тонны перегруженного Яваскрипта.

Кто-то скажет: сам виноват, ты нищеброд, живёшь далеко. Ищи другие способы. Но мне, знаете ли, пофигу. Дерьмо — оно и есть дерьмо само по себе, каким бы я ни был неподготовленным и «безответственным».

Чёрт с ними, с игровыми форумами и магазинами одежды. Но, блин, мне нужно просто перевести деньги, быстро и без проблем. Вместо этого мне рисуют надписи «быстро, надёжно, три степени защиты» внизу страницы. А на деле верхняя форма входа не работает, кнопка «Войти на сайт» посередине не работает, и я не могу совершать операции со счётом.

У почты Google есть опция перехода на «простой HTML». Прекрасная просто опция: нажал — и можно читать письма, можно писать письма, можно отправлять их в спам. Сделайте же хотя бы это!

Мне до лампочки ваш «минималистический стиль» с хипстерской графикой. До фени то, что у вас сейчас модно делать всё на этом JS какими-нибудь хитрыми фреймворками, замещая правильный <a href="…"> какими-нибудь document.open. Обезьян, которые делали фронтенд этого неработающего хлама, нужно гнать вон из профессии. Дилетанты!

По счастью, мне через пять минут позвонил обеспокоенный родственник и обеспечил все необходимые мероприятия по вызову врача.

Задолбали некомпетентные «разработчики»!