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

Программисты пишут на разных языках. С уважением, ваш К. О. Следствием этого факта является то, что некоторым программистам легче и проще работать с джаваскриптами, DOM, объектами и прочим в том же духе: совсем не вопрос написать скрипт, который получит от сервера данные в JSON, разберёт их, создаст необходимые DOM-структуры и встроит их в документ.

А вот другим программистам легче и проще написать 100500 шаблонов страниц, которые будут генерировать HTML на стороне сервера, а затем одним AJAX-запросом готовый код вместе с используемыми в нем скриптами будет просто вставлен в нужное место на странице.

Какой подход правильнее?

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

Другой специалист думает, что первый вариант вовсе не так хорош и имеет недостатки:

— программа получается достаточно сложной и объёмной, написать корректно работающий большой скрипт сложнее, чем сто маленьких простых;

— её работа зависит от корректности обработки браузером;

— её можно модифицировать на стороне пользователя, поэтому сложнее обеспечить безопасность и целостность данных;

— она сложнее в поддержке и развитии, так как более интегрирована сама в себя, чем множество независимых шаблонов.

Это чем-то напоминает сравнение Windows и UNIX: в одной из них принято писать многофункциональные приложения со множеством возможностей, очень большие и сложные, и потом выпускать новые версии с новыми возможностями;
в другой же считается правильным писать множество мелких утилит, каждая из которых мало что умеет, зато умеет хорошо и предсказуемо, и собирать из них системы разной сложности, как из кубиков.

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

Сижу на проекте коллеги. Вот несколько правил, которыми он руководствовался.

Если используете AJAX, никогда не забывайте формировать весь HTML и все биндинги на стороне сервера. Зачем передавать данные, если можно передать HTML?

Чтобы удобнее, например, реализовать галерею, сразу сформируйте HTML с инлайновыми джаваскриптовыми функциями goNext(), goBack(), closeGallery(). Куда же положить эти функции? Конечно ж, в глобал скоуп. «А что вообще можно класть в глобал скоуп?» — спросите вы. Конечно, всё. Всё, всё, всё и ещё раз всё. Зачем загружать себя модулями, низкой связанностью? Это всё брехня бюрократов и неталантливых сыщиков. Вообще все функции и переменные положим в один файл, чтобы «удобно» там было потом найти что-то. И вообще, классно ведь — один файл вместо тысячи, правда?

Для повышения крутости в инлайн-JS в HTML можно добавить несколькострочный код, что-нибудь из jQuery тоже пойдёт. Например, по DOM’у шариться через инлайн-JS — просто сказка!

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

Насчёт красных строчек: это же классно! Зачем делать мир чёрно-белым? Красные сообщения в консоли — это же прелесть, это красиво и разнообразно. Они никак не свидетельствуют о том, что что-то может идти не так. Они, как цветы на полянке в лесу, лишь украшают унылую консольку.

И напоследок: зачем использовать объекты JS? Всё же прекрасно хранится в дивах. HTML — это ж XML, так что вполне сойдёт для хранения данных. Просто ставишь display: none — и делов-то!

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

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

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

Получаться начало не сразу. По первости я это списал на незнание. Усиленно читал документацию, делал по примерам с официального сайта — но нет, не работало. Ладно, думаю, поищу в блогах разработчиков описания, на Хабре, ещё где-нибудь. Ввожу свой запрос в Гугл. Тот услужливо дописывает к моему запросу слова «not working». Улыбаюсь. Убираю самодеятельность поисковика, ищу, читаю. Нахожу решение, о котором ни слова в документации, удивляюсь, применяю. Вроде работает. Не дышу на то, что получилось, перехожу к следующей задаче. Всё повторяется по кругу: читаю документацию, пробую, не работает, в Гугл, тот дописывает к запросу «not working», убираю, нахожу решение, удивляюсь, не дышу, перехожу к следующей задаче.

В какой-то момент меня уже начало ощутимо напрягать, что в половине случаев документация непригодна и приходится искать решения на сторонних ресурсах. Гугл хоть и знает всё, но … И тут я наконец обратил внимание на то, что мне хотел сказать Гугл всё это время. Not working. Гугл действительно знает всё, а порой и старается донести своё знание даже по собственной инициативе, подсказать, предупредить вот в такой своеобразной манере.

Спасибо, Гугл, даже легче как-то стало. Этот проект завершаю и больше популярный блогодвижок не трогаю. Есть более пригодные инструменты для разработки, которые работают.

Мистика — это, как правило, непонятая закономерность. Если потрудиться, её можно найти. Хуже, когда неполадка уходит в прошлое.

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

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

Позвонил заказчик и сказал, что пытался обновить товары на сайте в одной известной CMS, но «всё пропало». Оказалось, что если при пакетной загрузке в выпадающем списке «Родительская группа товаров» выбрать эту же группу, то все товары и сама группа испаряются.

Логика заказчика: «Я хотел, чтобы товары попали именно в эту группу, так как именно её я и обновлял».

Логика системы: поскольку группа теперь не в корне, то нужно перенести её из корня. Группа становится подгруппой внутри несуществующей себя.

Похоже, у Уробороса всё-таки получилось себя съесть!

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

— Почём? Это смотря на какой CMS.

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

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

Скажите, зачем при малейшем чихе обращаться к ЕСИА? На всякий случай, чтобы ваша поделка не забыла об авторизованном пользователе?

Юзабилити? Не, не слышали.

Использование левых браузеров? Нет, верстаем только под «ишака».

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

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

Выбрал дату, выбрал мероприятие, выбрал время. Пока всё хорошо. Дошло до выбора места в зале. Вижу список рядов, где есть свободные места и указано, сколько именно. Ряды, где свободных мест нет, скрыты. Какой хороший сайт, однако! Тыкаю мышкой в нужный ряд. Открывается окошко с выбором мест. Внизу окошка — кнопочка «Положить в корзину».

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

Уже из любопытства решаю воспроизвести этот баг, открываю другой ряд и пытаюсь выделить все места. На этот раз натыкаюсь на костыль: в этом ряду нельзя занять все места, одно обязательно остаётся свободным. Освобождаю обратно все места и наудачу тыкаю кнопку «Добавить в корзину». Ура, вижу корзину с ранее исчезнувшими местами!

Нажимаю «Оформить заказ». Вижу список мест, итоговую сумму, но теперь нигде не написаны ни дата, ни время, ни название концерта. Перекрестившись, указываю свои контакты и нажимаю «Подтвердить».

Итак, у меня есть корзина с билетами и открывшееся окошко «Личный кабинет — изменение данных» с заполненными полями контактов, заполненным полем логина «as;iUh23» и пустыми полями для пароля. Меняю логин на Ivanoff, задаю пароль, подтверждаю пароль и… попадаю в свой личный кабинет с пустой корзиной. Телепатическим образом понимаю, что корзина кабинета Ivanoff пуста, потому что он ничего не заказывал. А заказывал билеты тот самый as;iUh23, но я не знаю его пароля.

Лезу в почту. Вижу два письма о создании двух кабинетов: as;iUh23, а потом Ivanoff. С паролями. Радостно пытаюсь зайти в личный кабинет as;iUh23, указывая присланный пароль. Неудача. Комментарий: «Пользователь as;iUh23 указал e-mail, который уже используется другим пользователем».

Закрываю страничку интернет-кассы, открываю IT happens.

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