70 лет в интернете
Совсем недавно вышла долгожданная операционная система Mac OS Lion. В нее вошло множество полезных изменений, повышающих удобство работы с системой и делающих ее более похожей на iOS. К сожалению, Apple не реализовала в операционной системе то, о чем многие пользователи (включая меня) просят уже давно и что существует в других ОС — resolution independence.
Что такое Resolution Independence, или независимость от разрешения, если по-русски? RI — это возможность операционной системы рендерить определенные элементы интерфейса без жесткой их привязки к пиксельной сетке: пропорции этих элементов по отношению к другим элементам могут меняться при изменении разрешения. Необходимо это для того, чтобы люди с особо крупными или особо мелкими разрешениями экрана видели элементы интерфейса такого же размера, как и остальные.
Частным, наиболее востребованным, случаем RI являются масштабируемые шрифты, независящие от разрешения. Не уверен, реализован ли в какой-то операционной системе полноценный RI, но независимые от разрешения шрифты реализованы в AmigaOS еще в 1991, в Windows — в 1995… сейчас 2011 год, и независимые от разрешения шрифты не реализованы в Mac OS до сих пор.

Чтобы понять проблему, давайте измеряем физическое разрешение стандартных экранов при помощи простого калькулятора.
В результате в каждой программе мне приходится увеличивать размеры шрифтов, чтобы с компьютером можно было комфортно работать… И то удается его сменить не во всех программах. Еще хуже дело обстоит с вебом. Теоретически достаточно в броузере увеличить размер шрифтов по-умолчаниию. И действительно, на всех сайтах в интернете, где тексты заданы в относительных величинах (em, %), текст становится нормального размера… К сожалению, 80-85% всех сайтов в интернете верстают мудаки, не заботащиеся о пользователях. Они задают размеры шрифтов абсолютными величинами… В результате при высоком разрешении текст всегда очень-очень мелкий.
Но уж лучше я везде буду вручную увеличивать шрифты, чем пользоваться ноутбуком с глянцевым экраном (кстати, у глянцевого Macbook Pro физическое разрешение 108 DPI, что тоже слишком мелко, но и не катастрофично).
Прослеживается еще одна неприятная тенденция — компания Apple постепенно уменьшает диагонали экранов в своих компьютерах iMac, оставляя прежние разрешения. То есть раньше разрешение 1920×1080 было у 23-дюймовой модели, и 2560×1440 у 30-дюймовой. Теперь же такие разрешения у 21.5 и 27-дюймовых моделей соответственно. DPI первой — 102.5, второй — 108.8.
Однажды я запустил Windows 7 в виртуальной машине на своем макбуке… В настройках экрана я выбрал использование шрифтов размером 125% вместо стандартных ста… И в миг система стала показывать шрифты удобоваримого размера! Во всех приложениях, на всех веб-сайтах! То, на что в MacOS у меня уходят часы настройки, в Windows решается за считаные секунды… уже 16 лет подряд!
Меня впечатлило одно из обсуждений проблемы Resolution Independence на маке — из него видно, что многие люди покупали топовые модели Macbook Pro и iMac с высоким DPI, а потом либо возвращали их назад в магазин, либо ставили Windows вместо MacOS, потому что элементы интерфейса системы на их экранах были слишком мелкими.

Меня очень угнетает тот факт, что проблема существует уже давно, а Apple не делает никаких телодвижений чтобы решить ее: концентрируется вместо этого на простоте перехода новых пользователей с iOS на MacOS вместо того, чтобы решить проблемы старых пользователей. Для меня это послужило веской причиной дальнейшего использования т.н. Hackintosh’а на домашнем компьютере вместо покупки iMac’а.
Надеюсь, эта статья поможет людям не допустить ошибку при покупке техники Apple.
Давно уже меня волнует проблема усталости глаз при работе за компьютером. В сотнях однообразных статей-советов на разных лайфхак-сайтах рекомендуют делать перерывы каждые N минут, использовать для этого специальные таймеры, делать упражнения, чтобы не развивалась близорукость. Но это как-то сложно и неудобно: я не хочу забивать напоминаниями свой календарь, GTD-планировщик или ставить на компьютер специальные раздражающие таймеры, заставляющие выходить из состояния «потока», чтобы давать глазам отдохнуть.
Несколько месяцев назад сотрудники нашли статьи (еще одна) об очках Gunnars, которые помогают меньше уставать при работе за компьютером. Я и раньше слышал о специальных очках для работы за компьютером, но это были какие-то отечественные поделки жуткого вида, эффект которых никто из моих знакомых не подтверждал.
Вскоре сотрудник купил себе очки Gunnars Halogen и подтвердил положительный эффект. После этого очки заказал и я.
О технологиях компании Gunnars и теоретических вопросах можете почитать в указанных выше статьях на Хабрахабре и на сайте Gunnars, я же собираюсь поделиться собственными впечатлениями.
Итак, небольшой обзор в пунктах:

Сейчас, спустя месяц после покупки, у меня сформировалось четкое мнение об очках Gunnars. Они не избавили от головных болей, не улучшили сон и не сделали мое зрение лучше, но в них я действительно устаю меньше при работе за компьютером, и резкость зрения к вечеру не падает.
Людям, проводящим за компьютером пару часов в день, такие очки ни к чему, тем же, кто за компьютером регулярно проводит более 5 часов, настоятельно рекомендую очки Gunnars. Цены на очки и, особенно, на доставку мне кажутся неоправданно завышенными, но зрение все-таки дороже.
Во избежание недоразумений хочу сразу сказать — эти очки не заменяют зрительные упражнения и перерывы в работе.
Если будете покупать до 30 сентября 2011 — можете воспользоваться моим 15% скидочным кодом ThankU11. Очки Halogen, например, с ним будут стоить не $189, а $160.
Помню, лет 5-6 назад гибкие методологии разработки казались чем-то очень простым, удобным и человечным — глотком свежего воздуха на фоне монструозных бюрократических процессов разработки ПО, царивших в то время.
Времена меняются, теперь Agile — это мейнстрим. И что же, благодаря этому повсеместно программные продукты стали делаться качественнее и удобнее для конечных пользователей? Проекты стали делаться без срывов сроков и раздувания бюджета? Несомненно — в редких случаях стало лучше, но в основном же все осталось примерно на том же уровне, что и было.
Знаете почему?
Процессы изменились, но люди остались прежними — такими же трусливыми некомпетентными балбесами, для которых формальное применение процесса важнее пользы (или вреда) от этого процесса. Ведь для большего нужно включать мозг, что-то анализировать, брать на себя ответственность.
Представим классическую для вебдванольного аутсорсинга ситуацию: клиент, не понимающий, чего же он хочет, менеджер проекта и аналитик (возможно, менеджер и аналитик в одном лице), роли которых сведены к интерпретации требований клиента на понятный программистам язык и контролю выполнения ими работы, ну и, конечно же, кучка инженеров, ожидающих любых указаний «сверху», требующих, чтобы все было описано как можно подробнее, и уверенных, что их задача состоит в том, чтобы писать хороший код и угождать руководству.
Такой продукт ОБРЕЧЕН! В лучшем случае, его удастся сделать, уложившись в срок, может даже в бюджет, но он никогда не станет успешным, понимаете?
Проблема в том, что к Agile-техникам люди подходят, как к формальному набору обрядов, которым необходимо следовать с религиозным бездумием. Типичный список обрядов таков:
Скажите честно, вы действительно думаете, что именно в этих пяти пунктах состоит Agile и именно это нужно, чтобы продукт, который вы делаете, стал успешным?

Давайте взглянем на Agile-манифест — документ, на основе которого как раз и появились гибкие методологии разработки:
- Люди и взаимодействие важнее процессов и инструментов
- Работающий продукт важнее исчерпывающей документации
- Сотрудничество с заказчиком важнее согласования условий контракта
- Готовность к изменениям важнее следования первоначальному плану
То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева.
По-моему, очень зрелые и трезвые мысли. Обратите внимание, в манифесте вообще ничего не говорится о пяти описанных выше обрядах! Более того, в определенных ситуациях эти обряды могут быть даже противоположны тому, о чем говорится в Agile-манифесте.
Успешное выполнение проектов и создание успешных софтверных продуктов — это, в первую очередь, вопрос культуры и опыта, но никак не методологии! Гибкие методологии — это всего лишь наборы рекомендаций и техник, без соответствующей культуры они не помогут вашему проекту ровным счетом ничем!
Scrum-совещания быстро станут унылой бюрократией, если члены команды и без того регулярно делятся друг с другом информацией о своей работе и проекте, либо если члены команды просто не видят пользы в этих совещаниях. Разделение проектной работы на итерации и их четкое планирование вряд ли даст какой-то ощутимый выхлоп, если работа над проектом состоит, в основном, в исправлении багов и вялой поддержке пользователей. Planning Poker вряд ли принесет хоть какую-то пользу, если команда состоит из одного разработчика, одного тестировщика и одного дизайнера, каждый из которых слабо разбирается в работе коллег. Code Review и TDD для одноразовых проектов (рассчитанных, например, чтобы один раз показать где-то на презентации и все) скорее помогут вам успешно просрать бюджет, чем сделать продукт лучше для целевой аудитории.
Работать надо не «чтобы было Agile», а с умом! Управление проектами — это не про методологии, это про людей, про их цели и ожидания, про их коммуникацию, про их мотивацию!
Я постарался собрать информацию о том, что же нужно для разработки успешных продуктов на основе публичной информации о разных проектах, данных от знакомых менеджеров и инженеров, личного опыта и здравого смысла. На мой взгляд, это:
Если вам есть, что сюда добавить — отметьтесь в комментариях к статье.
Нужно думать головой, а не пытаться следовать методологиям как религиям. Если людям не интересен проект, над которым они работают, а лидеры проекта не понимают, чего хотят — то проблема именно в людях, а не в «неправильной» методологии. Даже если будешь проводить стэндап-митинги, ретроспективы и играть в planning poker — проект всеравно сдохнет!
Работать с умом гораздо сложнее тупого следования набору формальных обрядов, но это единственный надежный способ делать качественные программные продукты в рамках разумных сроков и бюджетов.
Если вы не знаете, что означает методология Getting Things Done — пожалуйста, почитайте о ней, прежде чем продолжать чтение этой статьи.
Однажды ко мне в гости зашел приятель и спросил, чем я обычно занимаюсь по работе. Я просто открыл Remember The Milk и показал ему список выполненных задач.
Remember The Milk — это очень гибкое и удобное веб-приложение для работы со списками задач, не навязывающее каких-то жестких правил работы. Благодаря этому RTM можно использовать просто как линейный список задач(вроде списка покупок в магазине), но можно реализовать на его основе свою мощную GTD-систему. Причем, реализации у разных людей получаются иногда совершенно непохожими.
RTM существует уже 4 или 5 лет, и я пользуюсь им почти с самого старта проекта. За это время я перепробовал десятки разных GTD-планировщиков, но всякий раз возвращался назад к RTM — ни одно другое средство не было для меня столь же удобным.
В Remember The Milk у меня существует несколько списков задач: 4 базовых и 2-3 smart-list’а (о них позже). Для начала давайте поговорим о базовых списках:
Помимо самого текста к любой задаче в RTM можно добавить много полезной мета-информации:

Метки — пожалуй, единственный из атрибутов, который я использую всегда (кроме inbox’а: вы же помните, что он служит просто разгрузкой для мозга?). С помощью меток я разделяю задачи на контексты и проекты. Просто определил для себя, что теги начинающиеся с «p-» — это проекты, а теги начинающиеся с «@» — контексты, например:

В дальнейшем в один клик можно увидеть списки задач по определенным контекстам, проектам, приоритетам и.т.п. Результаты поиска можно сохранить и использовать заново в дальнейшем: это и есть т.н. smart lists — мощнейшая функция RTM.
Не знаю как вам, но мне тяжеловато оперировать большими списками задач, кроме того, я стараюсь работать сфокусированно, не отвлекаясь на ерунду: во время работы не хочу, скажем, видеть задачи, связанные с путешествиями или чтением литературы и.т.п., дома же я не хочу обращать внимание на рабочие задачи (трудоголизм до добра не доводит). В результате я просто создал 2 smart-листа на основе текущих задач в Actions:
Первое что важно запомнить — чтобы система была системой, а не просто набором слабо связанных задач, ее нужно регулярно поддерживать в актуальном состоянии.
Каждый день я просматриваю список задач в inbox, проставляю им необходимые теги, дедлайны, заметки и переношу их из inbox’а либо в Actions, либо в Someday, изредка в Waiting. Каждый день я расставляю приоритеты задачам в Actions. Задачи с высоким приоритетом почти всегда выполняю в тот же день. Стараюсь разбирать задачи пораньше, в течение часа после того как проснусь. Ежедневно на это уходит всего 5 минут.
Кроме того, раз в неделю, по воскресеньям, я просматриваю весь список задач в Waiting и Someday:
Я не живу по строжайшему расписанию и не делаю всегда то что нужно вместо того что хочется — у меня для этого сила воли не та, тем не менее, GTD помогает эффективно расходовать свое время и не забывать ни о чем важном (главное — не забыть записать в RTM). Но когда у меня появляется свободное время — стараюсь избегать прокрастинации и делать что-то полезное, что соответствует настроению, состоянию. Сегодня вечером, например, я собирался устроить занятие музыкой (учусь играть на гитаре) и почитать книгу, но почувствовал, что читать лень и пальцы болят еще с прошлого занятия, а вот написать что-то, что давно собирался, готов… Заглянул в список задач с тегом @writing — и сел писать эту статью. Все просто.
Большую часть того, что я описал, можно выполнить и в других GTD-инструментах. Почему же я использую именно Remember The Milk и чем он лучше других?
В следующий раз могу поделиться готовыми рецептами использования Remember The Milk.
За последние 3 года на этом сайте появилась всего одна новая статья.
Десятки раз я начинал писать что-то новое, но каждый раз решал что результат недостаточно хорош для публикации и бросал. У меня не было сил и времени заканчивать статьи, не было никакого желания доводить до ума устаревший движок блога, да и сама тематика блога казалась недостаточно полезной.
Со временем стало ясно: интересующие меня темы востребованы сильнее чем прежде, более-менее глубоких статей о них в рунете катастрофически мало, аудитория блога почти не уменьшилась за годы бездействия, а знакомые все так же настырно просят написать статьи на ту или иную тему.
Теперь, после некоторых изменений в моей жизни, могу и хочу снова заниматься этим сайтом: у меня вновь достаточно мотивации, сил и времени. Главная тематика сайта остается прежней: интернет, управление проектами и работа с людьми, технологии, лайфхаки и самосовершенствование, MacOS и продукция Apple. Разве что, теперь хочется больше писать об интернете и способах повышения качества жизни, меньше о технологиях.
Сайт переведен на другой движок и хостинг, чтобы можно было сконцентрироваться на текстах, а не на бекапах, доработке админки и.т.п. Старые комментарии, к сожалению, перенести не удалось. Прошу прощения за возможные глюки.
Хотите сделать сайт лучше? Расскажите, какие из тем блога наиболее интересным вам!