Программисты любят псевдографику. В любом языке полно составных знаков: ->, <=, ++, :=. По смыслу это один символ, но составленный из нескольких более простых. Мозгу требуются дополнительные усилия на то, чтобы считать и объединять такие конструкции на лету. Когда-нибудь, возможно, всех спасет Юникод, где символов хватит на сто языков вперед — если придумают удобный способ ввода и отомрет всё легаси. Но пока нам приходится читать и писать код в ASCII.

Казалось бы, дело швах. Но в апреле 2014 года Ian Tuomi придумал изящный выход: заменять часто встречающиеся последовательности лигатурами. Моноширинность при этом не ломается (если сделать ширину лигатуры кратной количеству символов, в нее входящих), код тоже не портится (лигатуры — чисто визуальная фича). Зато можно вместо -> нарисовать настоящую стрелочку. Это сильно облегчает мозгу сканирование и токенизацию кода: там, где по смыслу один символ, теперь и нарисован один символ. Самое главное, что это работает с любым, даже уже написанным кодом.

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

Страница соревнования: http://clojurecup.com/

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



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

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

Чтобы лучше понимать друг друга, давайте разговаривать об абстрактных апельсинах. Представьте себе Автокад, если слышали или доводилось попробовать. Можно Иллюстратор или КорелДро, что-нибудь далекое от программирования, чтобы абстрагироваться и рассуждать непредвзято. Почему они не могут работать в консоли?


Рис. 1. Абстрактный интерфейс в вакууме.

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

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

Итак, грехи:

1. Медлительность
2. Блокирующее взаимодействие
3. Неуместные ограничения
4. Ненастроенность
5. Несамостоятельность
6. Забывчивость
7. Гордыня

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

Предупреждение: Эта статья вас ничему не научит. Это очень высокоуровневый взгляд, мои мысли, моя рефлексия на вопрос, который для меня важен + небольшое этнографическое исследование по графическим клиентам git-а.

Поговорим о распределенных системах управления версиями.

CVS был грустным, медленным, неатомарным („ничего не трогайте, я коммичусь“), зато с нормальным клиентом в Эклипсе.

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

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

Один мой друг однажды сказал: „Я смотрю на код восемь часов в день, и я хочу, чтобы смотреть было приятно“. Он имел в виду качество кода, и здесь все понятно (или, наоборот, ничего не понятно). Но что с самим изображением? Все ли с ним хорошо? Можно ли сделать лучше? Это вопросы, которые совсем недавно пришли мне в голову, и я решил озаботиться ими серьезно. Оказалось, что это поле непаханое для улучшений.

В вашей системе время играет важную роль? Ваши пользователи/компоненты распределены по территории всего земного шара, или хотя бы нашей необъятной родины? Значит, вам нужны часовые пояса. Что ж, это просто. Самое сложное, что вам придется сделать — не запутаться. Об этом мы с вами и поговорим. Для начала вам нужно научиться правильно думать. Думая правильно, все остальное будет для вас либо самоочевидным, либо достаточно простым.

Начнем с часов. Все мы привыкли определять время, глядя на часы на стене. При работе с часовыми поясами такое время называется Wall clock time. В принципе, ничего плохого в нем нет, только в разных местах земного шара в один и тот же момент времени часы показывают разное время. Если задаться целью, можно придумать алгоритм перевода wall clock time одного часового пояса в wall clock time другого. Обычно надо прибавить/отнять разницу в часах между часовыми поясами, кроме (внимание) моментов перехода на летнее/зимнее время. Вот когда начинается переход, вычисления становятся по-настоящему сложными.

Нам же нужно что-то простое и пуленепробиваемое, как… целое число.

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

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

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

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

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

1. Все необходимые с точки зрения предмета поля (например, ФИО и дата рождения человека, если речь о паспортном столе);
2. Все необходимые для функционирования системы поля (те, без которых не будут работать алгоритмы — например, дата, с которой начинается предоставление услуг, чтобы делать по ним начисления);
3. Важные поля — такие, которые не необходимо, но желательно заполнить (например, обоснование вносимого изменения) — с той мотивацией, что пусть лучше пользователь попотеет, когда не нужно, чем забудет ввести значение, когда будет нужно.

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