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

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

West of House
You are standing in an open field west of a white house, with a boarded front door.
There is a small mailbox here.

> open mailbox
Opening the small mailbox reveals a leaflet.

> read leaflet
(Taken)
«WELCOME TO ZORK!

ZORK is a game of adventure, danger, and low cunning. In it you will explore some of the most amazing territory ever by mortals. No computer should be without one!»

Содержание:
Приветствие
Часть 1 — Преддверие
Часть 2 — Лес
Часть 3 — Поляна
Часть 4 — Вид каньона
Часть 5 — Зал

Часть 1,
в которой мы познакомимся с не всеми основами языка Haskell и напишем одну полезную для квеста функцию.

Итак, вы стоите в самом начале, перед закрытой дверью и видите почтовый ящик.

Добрый день, жители хабра! Я занимаюсь фрилансом (хотя это слово не очень люблю) на протяжении последних четырёх лет. В этом небольшом топике мне хотелось бы рассказать о различных способах вывода заработанных непосильным трудом денежных средств. Для начала стоит сказать о том, как именно организована моя работа. Я использую всего два варианта – oDesk и работа напрямую. С клиентами из России работать ещё не доводилось, так что о таких знакомых вариантах вывода денег, как WebMoney и Яндекс.Деньги речь идти не будет.

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

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

Приветствую!

Стало любопытно, насколько представлена тема Data Mining на хабре. Увидел лишь одну статью, посвященную данной тематике. Хочу сделать свой небольшой вклад в развитие данной темы.

Исторически сложилось, что у термина Data Mining есть несколько вариантов перевода:

• извлечение данных
• извлечение знаний, интеллектуальный анализ данных

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

Извлечение данных

Извлечение данных — это процесс нахождения, сбора информации, а также сохранения (конвертация) их в разных форматах. По простому, программы для извлечения данных называют парсерами (parser), граберами (grabber), спайдерами (spider), кроулерами (crawler) и т.д. Фактически, такие программы существенно облегчают всем жизнь, так как позволяют систематизировать данные (именно данные, а не знания!). Такие программы могут собирать адреса компаний в вашей отрасли, ссылки из нужных форумов, парсить целые каталоги, также могут служить отличным средством для составления баз данных.

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

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

При правильном подходе разработка новой функциональности может происходить довольно быстро и фокус тут в том, как не сломать при этом то, что было сделано раньше или же быстро понять, что именно ты сломал, и быстро это исправить. Каждый раз тестировать все детали и нюансы вручную очень долго и неэффективно, ведь в Эльбе сегодня уже более 400 «экранов». И проблема не только в том, что тестеры должны все это проверить вручную — очень много времени уходит на сценарий «тестер добавил баг — разработчик исправил баг — тестер проверил и закрыл/переоткрыл баг». Можно долго рассуждать о том, как трудно сохранить быстрорастущую систему в стабильном состоянии, почему код превращается в гавно, почему страшно делать исправления и никто не берет на себя смелость сказать дату релиза даже с точностью до месяца (потому что это было бы безответственно), но гораздо интереснее узнать о том, как сделать так, чтобы было хорошо.

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

Кто ответит за дизайн?

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

Несколько книг по разным темам, которые находятся в открытом доступе.

Основы программирования

• codebetter.com/karlseguin/2008/06/25/foundations-of-programming-ebook
• pine.fm/LearnToProgram
• netlib.bell-labs.com/cm/cs/pearls
• www.faqs.org/docs/artu
• savannah.nongnu.org/projects/pgubook