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

Недостаточные или ошибочные знания большинства IT специалистов относительно цветовоспроизведения, по моему мнению, объясняются тем, что на изучение теории цвета тратится очень мало времени, так как её основы обманчиво простые: так как на сетчатке глаза есть три вида колбочек, то смешивая определённые три цвета можно без проблем получить всю радугу цветов, что подтверждается регуляторами RGB или CMYK в какой то программе. Большинству этого кажется достаточно, и ихняя тяга к знаниям в этой области заканчивается. Но, процессы получения, создания и воспроизведения изображений готовят Вам множество нюансов и возможных проблем, решить которые поможет понимание теории цвета, а также процессов в основе которых она лежит. Этот топик призван восполнить пробел знаний в области цветоведения, и будет полезен большинству дизайнеров, фотографов, программистов, а также, надеюсь, другим IT специалистам.

Попробуйте дать ответ на следующие вопросы:

• почему физика не может дать определения понятию цвета?
• какая из семи основных единиц измерений СИ основывается на свойствах зрительной системы человека?
• какого цветового тона нет в спектре?
• как удалось измерить ощущение цвета человеком ещё 90 лет назад?
• где используются цвета, которые не имеют яркости?

Если хоть один на вопрос у Вас не нашёлся ответ, рекомендую заглянуть под кат, где Вы сможете найти ответы на все эти вопросы.

По работе я пишу тексты: посты на хабр, email-рассылку, статьи в СМИ. Пишу уже пару лет, последние полгода не меньше двух текстов в неделю. Значительным шагом в развитии моего навыка письма было открытие для себя информационного стиля и советов Максима Ильяхова.

Цель текста в информационном стиле — донести информацию до читателя. Информационный стиль: лаконичный, однозначный, точный и объективный. В информационных текстах нет лишних слов, эмоций, личного мнения. Они читаются легко и быстро.

Максим вводит понятие стоп-слов. Стоп-слова не характерны для текстов в информационном стиле и если вы встретили его — задумайтесь и перефразируйте это место. Стоп-слова это «кстати», междометия, модальные глаголы, отглагольные существительные и другие, всего около 100.

В какой-то момент мне стало сложно искать эти слова в текстах, поэтому я создал себе в помощь Test The Text. Test The Text выделяет в тексте слова нехарактерные для информационного стиля и объясняет почему.

Понадобилось мне прикрутить Lua к проекту на C++. Писать обертки в ручную — лень (слишком много писать), готовые не подходили по тем или иным причинам. Решил написать свою. А потому задался вопросом, как максимально упростить интерфейс? От одной только мысли об этом в голову лезли жутчайшие конструкции из шаблонов. Так оно в последствии и оказалось, но гораздо проще, чем представлялось.

В C++11 появились шаблоны с переменным числом аргументов, это позволяет писать шаблонные функции/классы так, как в C++03 было невозможно вовсе. Такие шаблоны сильно упрощают задачу.

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

В итоге хотелось увидеть интерфейс близкий к следующему:

lua.export_function(some_function);

Скорее всего, это последняя часть, опубликованная точно в срок. Мой отпуск почти закончился, и теперь писать по статье в неделю будет очень сложно. Спасибо всем, кому было интересно руководство «Haskell Quest Tutorial»!

Living Room
You are in the living room. There is a doorway to the east, a wooden door with strange gothic lettering to the west, which appears to be nailed shut, a trophy case, and a large oriental rug in the center of the room.
Above the trophy case hangs an elvish sword of great antiquity.
A battery-powered brass lantern is on the trophy case.

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

Часть 5,
в которой мы из маленькой ошибки выведем значительные следствия, а затем добавим в игру объекты.

Canyon View
You are at the top of Great Canyon on its west wall. From here there is a marvelous view of the canyon and parts of the Frigid River upstream. Across the canyon, the walls of the White Cliffs join the mighty ramparts of the Flathead Mountains to the east. Following the Canyon upstream to the north, Aragain Falls may be seen, complete with rainbow. The mighty Frigid River flows out from a great dark cavern. To the west and south can be seen an immense forest, stretching for miles around. A path leads northwest. It is possible to climb down into the canyon here.

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

Часть 4,
в которой мы займёмся рефакторингом, реализуем пару действий, узнаем о pattern matching и рекурсии, а так же сделаем из квеста настоящую программу.

Это первая ласточка в серии публикаций о новом динамическом HTTP маршрутизаторе поддерживающем GOV.UK. Это письмо проливает свет на наш порыв, объясняет решимость и подытоживает приобретенный опыт.

Зачем это нам сдалось.

На днях из Америки приехало два любопытных устройства: микрокомпьютер electric imp и оптический датчик уровня углекислого газа в воздухе K30. Каждый из них любопытен по-своему, расскажу немного о каждом из них и о их соединении.

Electric imp

Импы — это вид бесенят в немецком фольклоре. А также сокращение от Interface Message Processor, одного из проектов-предшественников Интернета. Создатели системы признают обоих предшественников. В жизни эта штука оказалась довольно покладистой, хорошо документированной платформой для разработки embedded приложений.

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

На одной улице в Бердичеве жили трое портных. У первого была вывеска: “Лучший портной в городе”, у второго — “Лучший портной в мире”, а третий написал: “Лучший портной на этой улице”.

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

Вы никогда, НИКОГДА не станете богатым от экономии на покупках в супермаркете!

Сотни миллионов людей в мире экономят как на покупках, так и на самих супермаркетах, не говоря уже о миллионах голодных, “экономящих” на еде вообще. Можно предположить, что достаточно большая часть экономящих людей попадается на удочку относительно больших чисел, получаемых умножением грошей на 20-30-40 лет… без какого-либо положительного финансового эффекта. Причина элементарна: экономический план на десятки лет — это оксюморон. Такой план не учитывает множество факторов, влияние которых весьма значительно и на более короткие сроки, поэтому он может называться мечтой, фантазией, как угодно еще, только не финансовым планом. Кризисы, биржевые скачки, инфляция, изменения в жизни, в работе, в уровне доходов, политической обстановке… да одна только кратковременная флюктуация в курсе валют может мгновенно уничтожить нажитое непосильным трудом (как и наоборот, кстати). Вы не разбогатеете за 20 лет, отказывая себе в шоколадках, или не тратя деньги на сигареты, или “собирая бутылки”. Вернее, не так. Ваш шанс разбогатеть за NN лет совершенно не зависит от ваших сегодняшних действий и еще меньше зависит от мелочей. А все потому, что

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

Про автора

Я разработчик и архитектор британской не софтверной компании. Имею 20 летний опыт в различных областях от высоко-уровневых UX/HCI до низко-уровневых реализаций баз данных.
Несмотря на то что я использую C# в своей повседневной работе, я писал промышленный код на многих языках, мои любимые Smalltalk, Python и совсем недавно F# (поэтому я и создал этот сайт).

Разглагольствования по поводу того чего я не понимаю

Вам надоела вся эта шумиха вокруг функциональных языков? Мне тоже! Я выскажу по этому поводу несколько причин почему разумные люди, такие как мы с вами, должны держаться подальше от этого.

Немного поясню: когда я говорю «статически типизированный функциональный язык программирования», я подразумеваю языки, которые поддерживают вывод типов по-умолчанию и прочее. На практике это означает Haskell и семейство языков ML (включая OCaml и F#).

Многочисленные статьи, посвященные TDD в общем и Unit-тестам в частности, как правило, оперируют довольно искусственными примерами. Например, давайте напишем функцию, которая складывает два числа и напишем для неё тест. Честно говоря, на таких примерах трудно оценить преимущества использования автоматизированных тестов.

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

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

Обычно, первое, что человек делает, встретив плохой код — ищет виноватого. Это сразу становится личной или племенной вендеттой:

«Как можно быть таким идиотом?»
«Кто виноват в том, что мой мозг взорвался от всей этой бессвязности и богохульства?»
«Кто оскорбляет <Название Компании>!?»

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

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

Мне давно хотелось иметь все STL-контейнеры и их методы в более наглядном и удобном виде. До сего момента я не знал о том, что на известном ресурсе посвященном С++ cppreference.com выложен полезный PDF-файл содержащий в себе как раз то что мне надо. Вот прямая ссылка на container-library-overview-2012-12-27.

В этом документе учтены как C++03, так и C+11. Оба помечены разными цветами, что достаточно быстро дает понять с какой версии стандарта доступен тот или иной контейнер.