Делала я свой первый сайт на Django. Ни Django, ни Python я ещё толком не знала, так что в учебниках и мануалах проводила вдесятеро больше времени, чем в IDE. Потихоньку-полегоньку сайт строился, проблемы возникали и решались, Гугл и документация — наши друзья.

На одной из страничек нужно мне было вывести список мероприятий в рамках проекта. Мероприятия добавлялись в админке, естественно; у каждого были параметр «дата и время проведения». Что характерно, в модели (и в базе) это один параметр типа datetime, а админка по умолчанию использует для него два поля — под дату и под время. На страничке же мне нужно было, чтобы был заголовок типа «Август 2014», а под ним — список мероприятий на этот месяц.

Для начала вывожу просто список всех событий, отсортированный по дате — всё работает. Курю маны, пишу группировки, чтобы события каждого месяца объединялись в один список. Навожу красоту, так, что имя каждого списка становится объектом datetime — так его можно будет потом красиво отформатировать в шаблоне — работает…

И тут я вижу странный баг.

Было у меня специально забито тестовое событие, которое уже прошло — от 1 июля 2014 (забивалось оно четвёртого). Казалось бы, заголовок над ним должен гласить «Июль 2014» — а на меня смотрел «Июнь». Проверяю базу — в базе июль. Проверяю группировку — всё верно, остальные месяцы правильные. Чешу репу, курю маны, ставлю отладочные выводы…

Доходит. В настройках проекта у меня было указано, что мы живём в России, более того — в Москве, и время у нас спешит на четыре часа по сравнению с UTC. Django умный и за временем следит сам; в админке же при вводе времени есть специальная кнопочка, которая подставляет в поле текущее время. Дату — первое июля — я ввела руками, а время поставила текущее: час ночи с копейками. В базу же записалось «правильные» время и дата — что-то около девяти вечера 30 июня. Django-то умный, он к датам положенные часы сам прибавляет, а вот функция группировки ничего про наше местоположение знать не знала.

Покурив маны, вытащила июль из июня.

Вывод: работать по ночам полезно для вашего кода!

Ну да, мы понимаем. Нужно как-то сделать вид хотя бы, что антинародные инициативы Госдумы имеют широкую народную поддержку. Но, умоляю, не надо от имени веб-разработчиков писать, что от интернета нужен отдых и что «Чебурашка» станет отличным подарком. Разберитесь в вопросе, пожалуйста.

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

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

Есть готовые решения. Весьма малая часть из них пишется в России.

И есть русский монополист на рынке коммерческих CMS в России. Да, именно тот, у которого функциональность, в нормальных системах укладывающаяся в одну строку, размазана на 400 строк;

тот, у которого заявленная (и объявленная главным конкурентным преимуществом) интеграция с жёлтой программой работает только в том случае, если на стороне жёлтой программы вывернуться наизнанку;

тот самый, который до сих пор не верит в то, что есть кодировка UTF-8, а всё остальное — экзотика, и считает, что основная и главная кодировка — CP1251, а UTF-8 надо отдельно включать при установке, а реализовывать её поддержку нужно перегрузкой функций;

тот самый, у которого ООП, но весьма своеобразный, сплошь из статических методов;

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

Очевидно, что это добро накроет нас всех, если отгородиться от цивилизованного мира железным занавесом.

Хотят ли этого веб-разработчики? За всех не скажу, не знаю. Лично я не хочу, и все, кого я знаю, тоже не хотят.

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

Вряд ли кто будет спорить, что карточка для метро на 20–60 поездок куда удобнее, чем целый мешок мелочи. Но какой смысл в карточках на одну-две поездки? Они абсолютно по всем параметрам проигрывают традиционным жетонам: занимают больше места, более уязвимы к физическим повреждениям, у них ограниченное время действия (кстати, совершенно непонятно, почему у карточек на одну поездку время действия меньше, чем у карт на десять; никаких технических причин сделать их такими же долговечными нет), они выбрасываются после одного раза, создавая горы мусора, стоят дороже (точнее, стоят жетон и карточка примерно одинаково, но жетон используется тысячи раз, пока не сотрётся или турист на сувенир не заберёт). У меня, как у технаря, сердце кровью обливается при виде такого варварства: высокотехнологичное изделие выбрасывается после первого использования, словно какой-нибудь пластиковый стаканчик! Чем не забивание гвоздей микроскопами? Почему нельзя было сделать, как в Питере, где жетоны и карточки прекрасно уживаются? Зато прогресс, блин!

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

Сверхъяркие синие светодиоды. Технологически их создание было гораздо сложнее, чем у зелёных или красных, поэтому они появились позже, и некоторое время считалось, что это круто. Многие производители начали лепить их куда ни попадя, например, в качестве индикаторов питания. Вот только совершенно непонятно, кому эта высокотехнологичность нужна, ведь дизайнеры и психологи давно знают, что самый спокойный цвет для человека — зелёный, именно зелёные светодиоды лучше всего смотрятся в качестве индикаторных (да и стоят дешевле). Нет, на системнике — вырвиглазно-яркий светодиод, который ночью освещает всю комнату мертвецким синим цветом, на роутере — четыре таких же. Последний писк моды — клавиатура, в которой синий индикатор NumLock ночью буквально выжигает глаза. Пришлось заклеить чёрным скотчем. Такой вот прогресс.

А в мире IT такое встречается вообще на каждом шагу.

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

Сайт надо непременно обвешать по самое не балуйся скриптами, всякими полупрозрачностями и анимацией, скрывающимися меню, а на фон ещё и картинку залепить на весь экран. В результате такое творение умудряется подтормаживать даже на i5 с четырьмя гигабайтами и каналом в 10 мегабит, при том, что полезной информации на странице — хорошо если 100 КБ. А на мобильнике этот сайт в лучшем случае просто тормозит страшно (не поверите, но далеко не везде 4G, кое-где даже 3G ловит с трудом), а в худшем им вообще невозможно пользоваться: всё расползается, половина функциональности не работает, причём критической. Попадался, например, сайт, где с мобильника невозможно было переключить страницу комментариев; был сайт, где нельзя залогиниться. Если мобильная версия есть, то урезана жесточайшим образом, иногда до полной бесполезности. Самое обидное, когда хороший сайт становится совершенно неюзабельным после апгрейда. Респект тем, кто хотя бы оставляет возможность вернуться к старому интерфейсу.

Люди, опомнитесь! Технический прогресс — не самоцель, а средство. Средство сделать жизнь людей лучше. И прежде чем прикрутить какую-нибудь модную нанофинтифлюшку (неважно, сенсорный экран или модную технологию на сайт), подумайте хорошенько: а точно ли пользователю от этого будет хорошо? Сомневаетесь? Тогда не нужно.

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

Полгода сайт прекрасно работал, хотя и практически не обладал дизайном. А сейчас на сайте сделали апдейт.

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

Вместо старого меню, прочерченного одной линией — новое, красивое меню с градиентом и тенями.

При заполнении адреса сайт услужливо подсказывает похожие названия улиц, пролистывающийся список помогает выбрать нужную…

Только вот после того, как ты вбил все данные, сами маршруты не отображаются. Обновляй, не обновляй, в каком браузере ни пытайся — пункт А показывает, пункт Б показывает, а маршрутов нет.

Честное слово, символично. До бешенства доводят те, кто, обвесив что-либо свистелками и перделками по самое дальше некуда, изничтожают при этом саму суть, ради которой всё и затевалось. Иногда — до полного нуля.

Программисты пишут на разных языках. С уважением, ваш К. О. Следствием этого факта является то, что некоторым программистам легче и проще работать с джаваскриптами, 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.