— Для чего нужны монады?
— Для того, чтобы отделить чистые вычисления от побочных эффектов.
(из сетевых дискуссий о языке Haskell)

Шерлок Холмс и доктор Ватсон летят на воздушном шаре. Попадают в густой туман и теряют ориентацию. Тут небольшой просвет — и они видят на земле человека.
— Уважаемый, не подскажете ли, где мы находимся?
— В корзине воздушного шара, сэр.
Тут их относит дальше и они опять ничего не видят.
— Это был математик, – говорит Холмс.
— Но почему?
— Его ответ совершенно точен, но при этом абсолютно бесполезен.
(анекдот)

Когда древние египтяне хотели написать, что они насчитали 5 рыб, они рисовали 5 фигурок рыб. Когда они хотели написать, что насчитали 70 людей, они рисовали 70 фигурок людей. Когда они хотели написать, что насчитали в стаде 300 овец, они… — ну, в общем, вы поняли. Так и мучились древние египтяне, пока самый умный и ленивый из них не увидел нечто общее во всех этих записях, и не отделил понятие количества того, что мы подсчитываем, от свойств того, что мы подсчитываем. А потом другой умный ленивый египтянин заменил множество палочек, которыми люди обозначали количество, на значительно меньшее количество знаков, короткой комбинацией которых можно было заменить огромное количество палочек.

То, что сделали эти умные ленивые египтяне, называется абстракцией. Они подметили нечто общее, что свойственно всем записям о количестве чего-либо, и отделили это общее от частных свойств подсчитываемых предметов. Если вы понимаете смысл этой абстракции, которую мы сегодня называем числами, и то, насколько она облегчила жизнь людям, то вам не составит труда понять и абстракции языка Haskell — все эти непонятные, на первый взгляд, функторы, моноиды, аппликативные функторы и монады. Несмотря на их пугающие названия, пришедшие к нам из математической теории категорий, понять их не сложнее, чем абстракцию под названием «числа». Для их понимания совершенно не требуется знать ни теорию категорий, ни даже математику в объёме средней школы (арифметики вполне достаточно). И объяснить их тоже можно, не прибегая к пугающим многих математическим понятиям. А смысл абстракций языка Haskell точно такой же, как и у чисел — они значительно облегчают программистам жизнь (и вы пока даже не представляете, насколько!).

Одним из краеугольных камней в Material design являются осмысленные движения между экранами. Lollipop предоставляет поддержку этих анимаций в форме фреймворка переходов между Activity и Fragment. Поскольку статей по данной теме не так много, я решил написать свою собственную!

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

Если вы желаете увидеть, что получилось — готовое приложение находится на GitHub.

Мне повезло стать Google Developer Expert Android в России, и поэтому я вдвойне переживаю, что не все из вас подготовились к релизу заранее. Сейчас мы с вами постараемся запрыгнуть на уплывающий пароход с зефирками.

Вы можете не читать, а просто посмотреть мой доклад на прошедшем DroidCon.

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

Моя стратегия разобраться в какой-либо теме — пару часов почитать Хабр. Я решил сэкономить немного времени таких же, как и я, и сделал небольшую подборку полезных и интересных материалов на тему UX. Сразу предупрежу, что получить профессиональный level up с помощью них не получится (для этого есть оффлайновые курсы), но вот вникнуть в тему и получить инсайты — запросто. И да, если есть, поделитесь ссылками на материалы, которые были для вас максимально полезными в свое время.

// <какой-то код>
 
int main ()
{
        constexpr int a = f ();
        constexpr int b = f ();
 
        static_assert (a != b, "fail");
}

Можно ли в приведенном выше фрагменте вместо комментария вставить такое определение f (), чтобы a получила значение, отличное от b?

“Разумеется, нет!” — скажете вы, немного подумав. Действительно, обе переменные объявлены со спецификатором constexpr, а значит, f () тоже должна быть constexpr-функцией. Всем известно, что constexpr-функции могут выполняться во время компиляции, и, как следствие, не должны зависеть от глобального состояния программы или изменять его (иными словами, должны быть чистыми). Чистота означает, что функция при каждом вызове с одними и теми же аргументами должна возвращать одно и то же значение. f () оба раза вызывается без аргументов, поэтому должна оба раза вернуть одно и то же значение, которое и будет присвоено переменным a и b… правильно?

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

Я ошибался.

Самый удивительный вопрос, который нам задают при назначении собеседований кандидатам на позиции стажеров, звучит так: «А что будут спрашивать?».

Уточним, вопрос этот чаще всего задают студенты. Те, для кого предстоящее собеседование будет первым или одним из первых в их профессиональной карьере.

В чем же причина такого вопроса?

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

Загвоздка состоит в том, что собеседование — это совсем не экзамен. Под катом ответ почему.

На днях исполняется 10 лет с тех пор, как я получил самую странную свою работу.

Шел 2005-ый год. Мой интерес к разработке системы управления контентом на Java для компании, недавно купившей наш стартап, неуклонно улетучивался, в то время как моей настоящей страстью была разработка компиляторов и инструментов языковой инфраструктуры (в основном для SBCL). Как-то раз я заметил открытую вакансию как-раз по этому направлению, что вообще-то было достаточно редким явлением. Я быстро прошел интервью — настолько быстро, что даже не задал нужных вопросов и проигнорировал несколько тревожных звоночков.

Меня ожидало захватывающее путешествие в мир ретрокомпьютинга.

Обычно дизайн приложения рисуется в векторном редакторе (например, Sketch), но типичным форматом картинок в приложении под Android является растровый (как правило, PNG). При разработке приложения необходимо для каждого векторного изображения заниматься утомительной работой по изготовлению набора растровых картинок для разных плотностей экранов. Количество таких комплектов может доходить до шести по числу возможных плотностей: ldpi, mdpi, hdpi, xhdpi, xxhdpi, xxxhdpi (плотность xxxhdpi необходима только для иконки приложения). При верстке иногда приходится задать в разметке явные размеры для изображения, что может потребовать перемасштабирования растровой картинки, а это, в свою очередь, наверняка приведет к появлению артефактов. К тому же наличие нескольких комплектов картинок отрицательно сказывается на размере выходного apk.

Вот уже как неделю английская версия the art of command line висит в секции trending на Github. Для себя я нашел этот материал невероятно полезным и решил помочь сообществу его переводом на русский язык. В переводе наверняка есть несколько недоработок, поэтому милости прошу слать пулл-реквесты мне сюда или автору оригинальной работы Joshua Levy вот сюда. (Если PR отправите мне, то я после того, как пересмотрю изменения отправлю их в мастер-бранч Джоша). Отдельное спасибо jtraub за помощь и исправление опечаток.

Итак, вы работаете на Java с самого её появления? Вы помните те дни, когда она называлась «Oak», когда про ООП говорили на каждом углу, когда сиплюсплюсники думали, что у Java нет шансов, а апплеты считались крутой штукой?

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

Привздохнув, произнесла:
«Как же долго я спала!»

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

Все примеры относятся к Linux, хотя многие из них справедливы для других *nix систем, я просто взял за основу самую активно развивающуюся ОС, к тому же ту, которая у меня перед глазами и где я могу быстро проверить предлагаемый код.

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

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

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

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

Абрахам Маслоу

Введение

Научное творчество само по себе процесс не тривиальный, требующий некоторого отрешения от внешнего мира. И нелинейный в плане распределения интенсивности во времени — порой проболтаешься впустую полгода, чтобы потом, в течение месяца-полутора решить большую часть беспокоящих тебя вопросов.

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

Вспоминаю времена, когда молодым и глупым аспирантом, я писал первый вариант кандидатского «кирпича», предназначенный для тщательного «вычитывания» мной и моим научным руководителем. Тогда я не знал о формате EPS, а поэтому экспортировал графики, построенные в Maple в *.bmp-растр и вручную… обводил их в MS Visio для последующей вставки в Word. Были и другие, не менее топорные глупости. Не удивительно, что тогда я проклял всё, и дал себе слово следующую диссертацию писать совершенно по другому.

Путем последовательных итераций, на сегодняшний день я пришел к такому вот решению:



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

Маленькая Лямбда решила, что уборку в комнате можно отложить и на потом.

Ленивые вычисления — часто используемая методика при исполнении компьютером программ на Haskell. Они делают наш код проще и модульнее, но могут вызвать и замешательство, особенно когда речь заходит об использовании памяти, становясь для новичков распространённой ловушкой. Например, безобидно выглядящее выражение

foldl (+) 0 [1..10^8]

потребует для своего вычисления гигабайты памяти.

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

Тема ленивых вычислений рассматривалась во многих учебниках (например, в книге Саймона Томпсона «Haskell — The Craft of Functional Programming»), но информацию о них, кажется, всё ещё проблематично найти в сети. Надеюсь, моё руководство посодействует решению этой проблемы.

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

Компания, где я работаю, разрабатывает программное обеспечение на C++ под Linux. Долгое время мы использовали Qt Creator, с редкими ребятами работающими из Emacs и Vim. Когда я сам попытался пересесть на Vim, я понял, что ситуация с плагинами для разработки на С++ очень не простая. Поработав немного с CTags, я быстро понял, что без напильника работать в Vim будет очень сложно.
К сожалению, с ростом опыта работы с Vim редактор в Qt Creator в режиме эмуляции устраивал меня все меньше, и в какой-то момент я решил потратить немного времени и разобраться, как же сделать из Vim нормальную среду.
Я очертил для себя четыре вещи, которые я бы хотел от среды разработки, и которых мне бы хватило в Vim, чтобы полностью на него перейти:

1. Автодополнение
2. Навигация по коду
3. Отладка прямо из среды
4. Интеграция с Git (в частности Blame прямо в редакторе, и Git Grep)

Автодополнение в Vim — это решенная проблема, и название у решения YouCompleteMe. Это очень качественный плагин, который реализует автодополнение для большого количества языков программирования, в частности Python и C++. Ходят слухи, что внутри Google YouCompleteMe решает и вторую проблему с навигацией кода, но использует для этого внутренные инструменты гугла для индексирования.

Интеграция с Git в какой-то степени решена с помощью vim-fugitive. Это не такая комплексная интеграция, как бывает у Jet Brains, или в Visual Studio, но сравнимая с тем, что предлагает Qt Creator. Те два сценария, которые нужны были мне: blame и grep — работают хорошо.

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

Многие слышали про тайловые оконные менеджеры, некоторые даже слышали о XMonad. А ребята из Google даже променяли Unity/Gnome на XMonad. Что же это такое, как это настраивать и как с этим жить? Краткий workaround для любителей кастомизировать всё подряд.

Привет, Хабр. Я знаю, что здесь уважают и любят выступления TED. Поэтому я не мог пройти мимо новости о том, что сайт ted.com после редизайна обновил плейлист «20 самых популярных выступлений на TED всех времен». Это яркий пример того, как путем послабления копирайта (все лекции TED находятся в открытом доступе, распространяются по лицензии CC, согласно которой разрешено все, кроме коммерческого использования) и организации краудсорсинга (все переводы выполняют волонтеры) можно добиться впечатляющих результатов…



Ранее на Хабре уже публиковался этот плейлист, но с тех пор он заметно обновился. Не изменился разве что лидер рейтинга — Кен Робинсон с выступлением «Как школы подавляют творчество».

Рейтинг составлен по количеству просмотров (в статистике учитывались данные с TED.com, Youtube, iTunes, Hulu, встроенных фреймов, количества скачиваний и т.д.)

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

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

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

Разработка Xenonauts заняла пять лет. На нее ушло в десять раз больше времени и в двадцать раз больше денег, чем я ожидал, но она стала настолько важной частью моей жизни, что мне даже немного жаль, что это путешествие завершилось. С разработкой было связано немало личных рисков. Когда она началась в 2009 году, мне было 22 года и я ничего не знал о разработке игр. Я потратил на этот проект все свои сбережения, значительную часть которых составляло наследство. Моим офисом была моя спальня, я работал над Xenonauts по вечерам и на выходных, после полноценной рабочей недели консультанта в KPMG, включавшей в себя три года экзаменов по бухучету (провал каждого из них привел бы к моему увольнению). К счастью, все закончилось хорошо. Эта статья представляет собой обещанный на Кикстартере дневник, в котором оцениваются все стороны разработки — правильно я поступал или нет. Надеюсь это будет интересно и возможно поможет кому-то избежать моих ошибок.