AETHER

О переносе RSS-ленты и закрытии Гугл Ридера

Александр Шабуневич — Thu, 14 Mar 2013 08:22:31 +0000

Сразу самое важное: я переношу RSS от Feedburner обратно на свой домен. Теперь RSS будет располагаться по адресу: http://feeds.aether.ru/EyeBeholder. Пожалуйста, обновите свою подписку, если вы всё еще хотите меня читать.

O технологии RSS вообще

Вчера Гугл объявил о будущем закрытии Гугл Ридера — одного из самых своих популярных продуктов в среде гиков. О популярности его можно судить хотя бы по тому, что 310 из 337 RSS-подписчиков данного блога пользуются именно им.

RSS так и не смог выйти в мейнстрим — о нём знают только гики и компьютерщики, а «простые» люди порой даже не догадываются. Firefox убрал иконку RSS из адресной строки еще в 4-й версии, Эппл отказался от RSS в Mountain Lion, теперь к ним, похоже, присоединяется и Гугл.

Надо сказать, что сама по себе технология RSS — классная штука, я к ней никаких претензий не имею. Но лично я не заходил в свой ридер уже наверное больше года. Правда, от Гугл Ридера я отказался еще раньше, сменив его на Tiny Tiny RSS, который хостится на моём сервере. А не заходил я в него из-за того, что информации для меня стало слишком много.

Через RSS я был подписан на 200+ сайтов, многие из которых ежедневно публиковали новости. Это всё или нужно прочитать, или оставить на потом, или пропустить и отметить как прочитанное. К последнему варианту приходилось прибегать всё чаще, но это убивает саму идею, а читать всё у меня ну никак не выходило. В общем, я отказался от чтения всех новостей подряд, о чем я уже писал, перейдя к форме фильтрации лучшего. В этом помогают твиттер, Призматик и сайты вроде Hacker News. Лично мне пока хватает и этого.

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

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

О переносе RSS-ленты блога

Как всё это связано с переносом ленты блога? Когда-то давно (в далёкой галактике, еще на другом домене) я перенёс свою RSS-ленту на платформу сервиса Feedburner. Тогда он еще был независимым (потом его купил Гугл) и модным сервисом, которым многие пользовались. Зачем он был нужен? Ну, как минимум для:

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

Есть и минус, конечно: все ваши подписчики принадлежат другой компании, т.к. в их RSS-ридерах вбит чужой домен. Если сервис работает стабильно, то этот момент можно игнорировать, но рано или поздно Гугл (наверняка) захочет прикрыть и Feedburner. И если закрытие ридера — это лишь клиентская проблема, то с пропавшим адресом RSS мало что сделаешь, если не озаботиться заранее.

Если вы хотите вернуть себе адрес RSS, у вас два варианта:

попросить всех пользователей заменить адрес RSS на новый и отказаться от Feedburner (и при этом потерять какой-то процент подписчиков)
продолжить пользоваться Feedburner на своём домене с myBrand, что даст больший контроль над адресом в будущем

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

Я пока выбрал второй вариант: Feedburner + свой домен, так как о судьбе Feedburner пока ничего не известно: возможно он проработает еще не один год. Таким образом, старый адрес RSS пока остаётся действующим. Но будет гораздо лучше если вы смените его сейчас на новый, чтобы в будущем избежать путаницы.

Повторю: я переношу RSS от Feedburner обратно на свой домен. Теперь RSS будет располагаться по адресу: http://feeds.aether.ru/EyeBeholder. Пожалуйста, обновите свою подписку, если вы всё еще хотите меня читать.

Две книги про тесты

Александр Шабуневич — Sat, 02 Feb 2013 11:11:57 +0000

Две последние книги, которые я прочитал, оказались про тесты: «The Art of Unit Testing with Examples in .NET» и «The RSpec Book: Behaviour-Driven Development with RSpec, Cucumber, and Friends». Последовательность прочтения как раз соответствует историческому развитию методологий.

The Art of Unit Testing

Книга «Искусство юнит-тестирования c примерами на .NET» («The Art of Unit Testing with Examples in .NET») посвящена даже не методологии TDD (Test Driven Development) в целом (про это как раз вторая книга), а теме написания правильных тестов. Это важный вопрос сам по себе, ведь тесты можно использовать и без строгого следования принципам TDD (то есть писать тесты не до кода, а после). При этом, плохо написанные тесты могут даже навредить (например, вселяя необоснованную уверенность в коде при рефакторинге).

Очень важно чтобы тесты были читаемыми (как и код), ведь тесты — это еще и документация. Например, не стоит делать в одном тесте более одного assert-а (чтобы не маскировать их при ошибках) или слишком увлекаться DRY (Don't Repeat Yourself), вынося инициализацию объектов из отдельных тестов в общие методы.

Кроме этого, в книге рассматриваются следующие вопросы:

Разные способы внедрения зависимостей: Inversion of Control (для конструкторов), Dependency Injection (для свойств), extract and override — их преимущества и недостатки.
Поясняется разница между mock (проверяют вызовы и фейлят тесты, вызывая assert) и stub, которые служат лишь «заглушками».
Даются советы, вроде того, что не стоит использовать более одного mock в каждом тесте (stub может быть сколько угодно), так как mock-и являются основным предметом проверки каждого теста.
Описаны основые «западни», при написании тестов, например, случаи, когда тесты недостаточно хорошо изолированы и зависят от других тестов.
Вопросы правильной организации, наименования тестов и прочие полезные приёмы.

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

Тесты уже прочно прижились в инструментарии программистов. Но как и любая другая область написание тестов требует своей культуры. Даже если не следовать в полной мере TDD, тесты писать скорее всего придётся — сейчас для этого созданы все условия (благодаря библиотекам и другим инструментам). А как их лучше писать расскажет данная книга. Уверен, что даже человек с опытом написания тестов сможет найти в ней что-то полезное. ★★★★☆

The RSpec Book

С этой книгой я решил ознакомиться так как в последнее время всё чаще встречаюсь с понятием BDD (Behavior Driven Development) — своего рода, следующей версией TDD. Почти во всех языках программирования это сейчас является трендом: постоянно появляются новые библиотеки и фреймворки в этом стиле, и все большее количество проектов выбирают BDD для написания тестов. Сначала мне было не слишком понятно, чем вообще отличается BDD от TDD. Данная книга как раз ответила на этот вопрос.

Небольшое отступление про TDD/BDD

TDD, если вкратце, является такой практикой программирования, в которой тесты пишутся до рабочего кода. Это может показаться несколько нелогичным, ведь программистам платят именно за написание кода. Кроме того, писать код — наше самое любимое занятие. Но, думаю, многие знакомы с ситуацией, когда начинаешь писать код без особого предварительного планирования, а потом получается полная каша, которую несколько раз приходится переписывать. Так при чем тут тесты?

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

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

A general rule of thumb is that if the code is hard to use in examples, it’s going to be hard to use everywhere else.

То есть вы не пишете тесты, чтобы проверить, правильно ли работает код, а пишете код, чтобы проверить, правильно ли исполняются функциональные требования в виде тестов. И тесты теперь становятся не просто инструментом для проверки ошибок: теперь они являются формальным документом (протоколом), по которому работает программист. Более того, написание тестов по сути является фазой дизайна — именно в этот момент вы проверяете, насколько ваши API будут удобны в использовании.

Данный подход характерен и для TDD, и для BDD, но последний пошел несколько дальше, меняя формат тестов на более «человеческий». Если TDD-тесты пишутся тестерами (или самими программистами) для программистов, то BDD-тесты пишутся еще и для заказчика. Более того, кроме тестирования юнитов (отдельных объектов), большое внимание уделяется тестированию поведения системы в целом (behavior) — в каком-то смысле это замена интеграционному тестированию и ATDP (Acceptance Test–Driven Planning).

Rspec и Cucumber

Книга рассказывает о двух основных продуктах для BDD-тестирования в мире Ruby: RSpec и Cucumber. Первый отвечает за тестирование объектов (аналог TDD), второй — за описание и тестирование поведения системы (аналог ATDP). Одно из главных отличий от более традиционных методов заключается в упрощении восприятия тестов и спецификаций.

Восприятие упрощается даже из-за использования языка, относящегося не к тестам, а к поведению: Given/When/Then. Спецификации Кукумбера вообще пишутся просто на английском (их можно писать даже на русском). При этом в Кукумбере есть несколько очень интересных фич: например, работа с шаблонами и таблицами подставляемых данных. Тесты RSpec очень похожи на TDD, только вместо assert обычно используется should, а вместо названий методов (типа testEmptyStringShouldBeNil) — строки (it "should return nil with empty string").

Но отличие не только в синтаксисе, а скорее в общем подходе. BDD-подход был разработан как ответ на запросы программистов, которые не знали с чего начать в TDD. Предполагается, что разработка должна проходить в виде цикла:

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

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

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

Все примеры в книге даны на Ruby, но это не мешает тем, кто пишет на других языках. На некоторых платформах тот же Кукумбер можно легко применять для тестирования без изменений синтаксиса (например, для разработки iOS/андроид-приложений есть Calabash), а синтаксис RSpec послужил источником вдохновения для многих библиотек. Например, для JavaScript есть Jasmine, которую использует Angular.js.

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

Ссылки по теме:

Kindle Paperwhite против Nook with GlowLight

Александр Шабуневич — Sun, 27 Jan 2013 09:30:53 +0000

Полгода назад я написал заметку о ридере Nook Simple Touch with GlowLight. Тогда я его назвал «идеальным ридером». И на то были причины. Единственный из (современных) ридеров на е-инке с подсветкой, да еще и на базе Андроида, что открывает широкие возможности для кастомизации и хаков.

Но спустя несколько месяцев главный конкурент Барнса и Нобеля — Амазон — ответил выпуском Kindle Paperwhite, который кроме подсветки имеет еще и новый экран с большим разрешением. И вот теперь, когда я стал счастливым обладателем обоих девайсов, я могу их субъективно сравнить и решить, какой же из них лучше.

Железо

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

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

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

Экран Нука (сверху) против Киндла (снизу): шрифт разный, но сразу видно, что у Киндла разрешение выше, а буквы контрастнее.

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

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

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

Софт

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

Стандартные устройства

«Из коробки» устройства обладают похожей функциональностью: они могут читать «свои» форматы (хотя формат Нука — epub — более привычен), имеют словари и кое-какие другие фишки. Наверное, единственным преимуществом Нука над Киндлом я могу назвать чуть более продвинутый стандартный ридер. Во-первых, он умеет переносить слова, чего Киндл никак не научится делать. Во-вторых, открывает PDF в текстовом виде (т.н. режим reflow) — что лично для меня важно, так как читать обычный PDF на таком маленьком экране — удовольствие для мазохистов. Формат EPUB лично мне тоже более понятен — он чаще встречается в интернете.

Правда, у Киндла тоже есть свои преимущества. И главное из них — облачная инфраструктура и экосистема Амазона, а именно, одна, но очень крутая фишка: отправка документов на специальный адрес почты, которые затем попадают на ваши устройства. Более того, этот сервис умеет конвертировать документы (PDF, DOC и другие) и странички сайтов в книги, которые потом очень приятно читать с е-инка. По сути, это аналог сервиса Pocket, для которого я даже писал свой хак, чтобы подружить его с Нуком. Так вот, для Киндла этого не нужно — всё работает из коробки.

Вот парочка сервисов, которые занимаются отправкой веб-страниц на Киндл: FiveFilters Kindle-It, Klip.me. Кроме того, Instapaper и Readability тоже умеют делать периодические дайджесты ваших сохранённых статей. Раньше я считал, что такая связь является односторонней, но я был не совсем прав: если поставить на все устройства программу-клиент от Амазона, то статус прочитанных статей, автоматически сохраняемый в облаке, будет синхронизирован на всех устройствах.

Еще парочка преимуществ Киндла без джейлбрейка:

Можно установить англо-русский словарь (в Нуке есть только английский толковый)
Можно закачать свои шрифты

Несколько слов о конвертации

Во-первых, конвертировать документы в MOBI оказалось проще, чем я думал. Через программу Calibre или через облачный сервис самого Амазона практически любой документ можно качественно сконвертировать. Например, FB2→MOBI сохраняет форматирование, содержание и сноски. EPUB→MOBI на Киндле выглядит местами даже лучше, чем родной EPUB на Нуке. Конечно, конвертация — это дополнительный шаг, который иногда делать лень, но если вы купили Киндл и не хотите делать джейл с этим придётся смириться.

Мои личные наблюдения:

FB2, EPUB лучше конвертировать в MOBI через Calibre.
PDF лучше отсылать на почту yourname@kindle.com с темой «convert». Calibre тоже умеет конвертировать PDF, но выглядит он при этом совершенно ужасно.

Если в PDF много картинок, которые Амазон порой вырезает, то можно попробовать прогнать его через утилиту k2pdfopt, которая преобразует его в набор картинок с рефлоу. Но это не всегда бывает удобно и скорее пригодится в крайнем случае.

Устройства с джейлбрейком/рутом

Сделать джейлбрейк на Киндле просто — закидываете файл на Киндл, перезагружаете и всё готово. Сделав джейлбрейк, вы сможете:

Установив JBPatch, настроить встроенную читалку: уменьшить поля, добавить переносы (для русских и английских текстов), сделать поиск по всем словарям сразу и т.д.
Поставить Coolreader (или HackedUpReader — правда его я так и не смог установить), которые позволяют читать fb2/epub и обладают более гибкими настройками, чем встроенная читалка
Настроить синхронизацию коллекций (у Киндла нет папок) с Calibre при помощи Collections Manager
Убрать рекламу, которая, хоть и не мешает, но заставляет делать лишний жест при открытии обложки (лично я рекламу убрал за деньги, но есть и другие способы)
Много ссылок по теме хаков для Киндла Тач/Paperwhite

Это то, что интересовало лично меня, хотя джейл позволяет делать не только это. Надо сказать, что возможности Киндла (даже с джейлом) сильно уступают Нуку, так как Нук работает на Андроиде, что, конечно же, гораздо круче, чем простой линукс. Сделав рут для Нука, вы получаете доступ ко всему маркету (правда, не все программы работают на Андроид 2.1), а Киндл имеет лишь несколько самописных программ.

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

Проблемы с типографикой

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

При этом Киндл не умеет расставлять переносы ни в английских, ни в русских текстах. Это можно поправить с помощью джейлбрейка, но лишь для формата MOBI, а для нового родного формата (AZW3) пока ничего не поделаешь.

Правда, некоторые сервисы (в частности те, что я привёл выше), отправляющие документы через личный адрес почты @kindle.com, сами вставляют мягкие переносы в английские тексты, что несколько облегчает ситуацию.

Получается, Амазон принял самое идиотское решение в этом вопросе: не сделав механизм переносов, полностью выравнивает тексты, создавая порой огромные дыры между словами (особенно это актуально для русского языка). На это ругается и Грубер:

Another typographic boner: the Kindle still lacks hyphenation but yet insists upon full-justified text. Full justification without hyphenation inevitably results in unsightly gaps between words on a few lines each page. Any layout engine that doesn’t do hyphenation should default to ragged-right justification — but a dedicated e-reader in 2012 has no excuse for not including a good auto-hyphenation algorithm.

Пока что я не понял, как до конца решить эту проблему. Сейчас я прогоняю все свои книги через Calibre, которая умеет сохранять их в старом формате (MOBI) и делать выравнивание по левому краю. Как вариант, можно читать FB2 в Coolreader (хотя на мой взгляд он ещё сыроват). Но для документов, пришедших из облака, остаётся лишь терпеть и стараться не замечать этих дыр.

Выводы

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

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

Если вас не интересуют хаки и джейлы (и вас устраивает стандартная функциональность), то смело берите Киндл, ведь от Barnes & Noble ждать крутой облачной функциональности не стоит.
Если же вы не против слегка поковырять устройство, чтобы заставить его работать так, как надо вам, то я советую подождать, пока не выйдет новая модель Нука. Уверен, она будет не хуже амазоновской по экрану, зато андроид позволит вам настроить всё так, как захотите.

Обновление (29 января 2013): недолго музыка играла. Сегодня Киндл самостоятельно обновился до прошивки 5.3.3, что снесло и джейлбрейк и jbpatch. Джейлбрейк частично сохраняется (хотя сам по себе он довольно бесполезен), а вот с jbpatch — сложнее. Его пока нет для этой версии прошивки, а без него ни переносов, ни уменьшения полей не видать. И главное, отключить OTA (обновления по воздуху) никак не получится, если вы пользуетесь вайфаем. Остаётся ждать, пока чудесный ixtab сделает обновление. А Амазону еще один минус с точки зрения кастомизации.

Обновление 2 (11 февраля 2013): чтобы прошивка не обновлялась автоматически, нужно поставить USBNetwork патч — это даёт возможность заходить на Киндл по SSH (при входе по SSH нужно ввести команду mntroot rw, а при выходе: mntroot ro, чтобы поулчить права на редактирование файлов). Затем нужно следовать этой инструкции. Но чтобы точно убедиться, что обновления теперь отключены, нужно ждать до следующего апдейта.

Если вас интересуют обновления по этой теме, то подписывайтесь на мой твитер.

Обзор книги «97 Things Every Programmer Should Know»

Александр Шабуневич — Wed, 16 Jan 2013 18:54:57 +0000

Решил писать небольшие отзывы по прочтённым книгам технического толка. Первой прочтённой книгой в этом году стала «97 вещей, которые должен знать каждый программист» («97 Things Every Programmer Should Know»). Это книга о программировании «вообще», best practices, так сказать.

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

Советы даются вроде таких:

Изучайте больше языков программирования (можно каждый год учить новый): это расширяет кругозор;
пишите тесты (для людей) — они не просто помогают искать ошибки, а служат своего рода документацией и планированием для кода;
упрощайте всё и вся, не повторяйте код, разделяйте методы и т.д.;
знайте свой следующий коммит;
не злоупотребляйте комментариями: старайтесь комментировать лишь то, что код не может рассказать сам;
знайте свои инструменты (IDE) и изучите unix tools;
и тому подобное — достаточно посмотреть содержание книги.

Советы часто из рода капитанских, но я такие вещи воспринимаю положительно: повторение мать учения. Книга, конечно, не на уровне с каким-нибудь легендарным Code Complete — всё же краткий формат скорее служит шпаргалкой, а не полноценным учебником. Но почитать книгу, чтобы «освежить знания», вполне можно. ★★★☆☆

Про мою схему метро

Александр Шабуневич — Fri, 11 Jan 2013 11:30:41 +0000

Ну ладно, если уж другие участники написали о своих схемах, напишу и я.

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

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

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

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

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

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

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

Я оставил объединение станций с одинаковыми названиями (как и на моей прошлой схеме), что, наверное, является неким промежуточным вариантом между всеми отдельными станциями и всеми объединёнными. Такое решение может показаться спорным, но это одна из фишек моей предыдущей схемы, от которых мне не хотелось отказываться.

Дальше я все же поддался своим сомнениям и решил схему сделать с круглой кольцевой. Это следующий черновой вариант:

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

Потом я эту схему распечатал и понял, что шрифты слишком тонкие (я использовал бесплатный шрифт PT Sans Narrow). Его хорошо видно вблизи, но при печати и рассматривании на расстоянии он читался слишком тяжело (на мой взгляд, от этого же страдала схема Лебедева, например). В общем, я решил использовать полужирное начертание, которое, хотя и было слишком плотным, на мой взгляд, все же читалось гораздо легче обыкновенного. В метро немало людей со слабым зрением и доступность тут важнее визуальной равномерности информации.

В общем, потом были добавлены другие детали: река, всякие подписи, необходимые по ТЗ и прочая информация (необходимость которой порой находилась под вопросом). Что получилось можете увидеть сами. Раз уж в финал я не прошел, можно похвастаться тут:

PDF, отосланный на конкурс (есть еще вариант с будущими ветками).

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

В целом, не мне судить о том, что получилось, а что нет. Посмотрим, что покажут другие участники (я пока видел только версию от РИА Новости). В любом случае я рад, что московский метрополитен пошел на такой шаг и объявил народный конкурс. Любая из схем, представленных в финале будет лучше той, что сейчас красуется в вагонах. И это самое главное.