To follow the path:
look to the master,
follow the master,
walk with the master,
see through the master,
become the master.

«Лучший способ писать — это переписывать» Пол Грэм, «The Age of the Essay»

Преред курсом Сергея Абдульманова ( milfgard) я взял для себя квест — структурировать все статьи Грэма. Пол не только крутой программист и инвестор — он мастер лаконичного письма. Если milfgard назвал свой курс для контент-менеджеров "Буквы, которые стреляют в голову", то Пол Грэм стреляет из «по глазам» (кто играл в Fallout 2 тот поймет).

А еще мне захотелось освоить Lisp. Чисто так, чтобы мозг поразвивать, потому что крутые люди — Грэм, Кей и Рэймонд, Моррис — говорят хором: «Учите Lisp».

На данный момент Пол Грэм написал (по крайней мере, я нашел) 167 эссе. Из них на русский переведены 69.74(+10). Если читать по 1 статье в день (что очень хороший результат, потому что я после одной статьи хожу задумчивый неделю — голова кипит как после отличного мастер-класса, а иногда и как после двухдневного интенсива), то процесс займет полгода.

Под катом — список всех статей со ссылками на оригинал и с переводом (если он есть). Подборка живая (так что, как обычно, добавляйте в избранное, потом прочитаете) и будет дополняться по мере обнаружения свежака. Еще вы найдете переведенную на 8/15 книгу «Хакеры и художники» и 4/25 перевода книги «On Lisp». Так же я приведу свою подборку топ-5 статей Пола Грэма, с которых я бы рекомендовал начать знакомство с этим автором.

— ООП не сможет больше спасать нас от «Облачных монстров».

Примечание переводчика: Есть два понятия — параллельность (выполнение одновременно, независимо) и конкурентность (выполнение по шагам, поочерёдно, но одновременно несколько задач) и как всегда, мне пришлось поломать голову подобрая правильные термины.

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

Возможно вы уже слышали такое выражение, вроде: “Clojure”, “Scala”, “Erlang” или даже “Java теперь имеет лямбды”. И вы имеете хоть и отдалённое представление о «Функциональном программировании». Если вы участник какого-либа программисткого сообщества, тогда эта тема могла уже вами обсуждаться.

Если вы поищите в Google по словосочетанию «Функциональное программирование», вы не увидите что-то нового. Второй язык из созданных ранее уже охватывает эту тему, он был создан в 50-ых и называется Lisp. Тогда, какого чёрта, эта тема стала популярна только сейчас? Всего то 60 лет спустя?

В начале, компьютеры были очень медленными

Верите вы этому или нет, но компьютеры были нааамного медленнее чем DOM. Нет, действительно. И в то-же время были 2 основные идеи в соглашении по дизайну и реализации языков программирования:

• Начинайте исходя из архитектуры фон Неймана и добавьте абстракцию.
• Начните с математики и удалите абстракцию.

«Инструкция создания функционального приложения», часть 1.

«Мне кажется, что понимаю функциональное программирование на базовом уровне, и я даже писал простые программы, но как мне создать полноценное приложение, с реальными данными, с обработкой ошибок и прочим?»

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

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



Лекция была прочитана Борисом hr0nix Янгелем на факультете компьютерных наук, открытом в Высшей школе экономики при поддержке Яндекса. Сам Борис окончил ВМиК МГУ и Школу анализа данных Яндекса. Работал в Microsoft Research Cambridge в группе Кристофера Бишопа над фреймворком Infer.NET. Сейчас Борис — ведущий разработчик поиска Яндекса.

Под катом — расшифровка рассказа.

Можно прочитать много книг по базам данных, написать кучу приложений на аутсорс или для себя. Но при этом невозможно не наступить на грабли, при работе с действительно большими базами/таблицами особенно, когда downtime на большом проекте хочется свести к минимуму, а еще лучше совсем избежать. Вот здесь самые простые операции, как например изменение структуры таблицы может стать более сложной задачей. Наиболее интересные случаи, проблемы, грабли и их решения из личного опыта с которыми нам на проекте Pushwoosh пришлось столкнуться описаны под катом. В статье нет красивых картинок, зато есть много сухого текста.

Статья «Навыки .NET-разработчика» была первым моим аналитическим исследованием востребованности навыков на рынке труда, в котором я показал потребности близкого к нам российского рынка в специалистах моей профессии. В этом материале я представляю сравнение с зарубежным рынком. Говорят, что наш IT-рынок в целом и используемые нами технологии в частности отстают от Запада на несколько лет. Давайте вместе посмотрим «за рубеж» и попробуем понять, так ли это и есть ли нам чему поучиться.

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

Представляем наглядное пошаговое руководство по поиску и устранению ошибок в коде для языка Python, которое мы в Alconost перевели специально для Хабра. Следуйте по стрелкам, чтобы определить вероятную причину проблемы — и, если первое из найденных решений не подходит, возвращайтесь и пробуйте еще.

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


Картинка кликабельна

Переведено с любовью к коду компанией-локализатором Alconost.

Сейчас уже сложно вспомнить тот момент, когда я впервые осознал, что выделять функции из больших кусков полезного кода, вообще-то, хорошая идея. То ли я получил это знание из “Совершенного кода”, то ли из “Чистого кода” — сложно вспомнить. В целом, это не особенно важно. Мы все знаем, что должны разносить бизнес-логику по хорошо проименованным функциям. Самая длинная функция, которую я когда-либо видео в жизни была длиной в 5к строк. Я лично знаком с тем “программистом”, что написал тот код. Помню, как впервые встретил эту функцию. Не сложно предсказать, что моей первой реакцией было: “Какого чёрта!!! Кто произвёл на свет этот кусок дерьма???”
Да, представьте себе, этот “программист” до сих пор слоняется тут в офисе, где я сейчас работаю над текущими проектами. Не хочу углубляться в эту историю, но хочу упомянуть, что та функция длиной в 5к строк была ядром программы, размером примерно в 150к строк. Разработка программы в конце концов зашла в тупик, из-за той ужасной функции, которая крайне негативно влияла на архитектуру приложения. В конце концов было принято решение о переписывании приложения с нуля.

Прочитал я тут на Хабре отличную статью «Почему программировать так тяжело?» и сразу проникся к ней симпатией. «Боже мой!» — подумал я. Наконец-то можно показать толковый и взвешенный текст некоторым моим знакомым, считающим меня высокооплачиваемым бездельником, объяснить родственникам, что это за работа такая — «кнопки целый день тыкать» и предоставить защитившим кандидатские диссертации друзьям доказательства того, что и я тут тоже не коровам хвосты кручу в рабочее время. «Какая прекрасная статья!» — думал я. Наконец-то кто-то понял всю суть работы программиста и объяснил её сложность понятным языком!

И лишь одной малюсенькой детали в этой статье не хватало. Правды.


Правды о том, что программировать легко и приятно, что сложности надуманы, а плюсы работы — недооценены. И я думаю стоит исправить эту несправедливость, написав такую статью. И нет, я не буду тут скатываться в трёп о высоких зарплатах, востребованности на рынке и высокой мобильности. Это всё ведь не о программировании, это о стиле жизни программиста, что не совсем то. А мы ведь на Хабре, а не на Мегамозге каком-то, поэтому давайте рассмотрим именно программирование, во всей его завораживающей красоте и устрашающей мощи!

Первое видео курса

Массачусетский технологический институт выложил в свободный доступ курс лекций по теме «Теория и аналитика игры в покер» (на английском языке). Доступны видеолекции, конспекты и специальные заметки по курсу. Это событие – часть программы OpenCourseWare, которая посвящена организации бесплатного доступа к избранным лекциям института для всех желающих – даже для тех, кто не учится в нём.

Помните, как в школе многие говорят: «Ну зачем мы это учим, нам это не пригодится!»?



Так вот, лекции по покеру – пожалуй, могут оказаться не просто интересными, но и весьма полезными с практической точки зрения.

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

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

На Хабре не так уж и много статей о Clojure, и это печально, намерен это исправить. Ниже я расскажу об отличном на мой субъективный взгляд инструменте — языке программирования Clojure и его библиотеках для создания веб-приложений.

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

Код в статье приводится на scala, однако рассматриваемый подход может быть реализован на многих других языках (c++ с помощью макросов, java с помощью JetBrains MPS и т.д.). Наиболее близким аналогом рассматриваемого подхода является способ обработки ошибок в haskell.

Я хотел бы рассказать вам об утилите, с которой вы сможете забыть о боли создания документации для Web API. О том как это сделать прошу всех под кат.

^{Капитан Немо у штурвала «Наутилуса»}

Индексы — один из самых мощных инструментов в реляционных базах данных. Мы используем их, когда нужно быстро найти какие-то значения, когда объединяем базы данных, когда нужно ускорить работу SQL-операторов и т.д. Но что представляют собой индексы? И как они помогают ускорять поиск по БД? Для ответа на эти вопросы я изучил исходный код PostgreSQL, отследив, как происходит поиск индекса для простого строкового значения. Я ожидал найти сложные алгоритмы и эффективные структуры данных. И нашёл.

Здесь я расскажу о том, как устроены индексы и как они работают. Однако я не ожидал, что в их основе лежит информатика. В понимании подноготной индексов также помогли комментарии в коде, объясняющие не только как работает Postgres, но и почему он так работает.

После выхода на экраны российских кинотеатров эпического «Mad Max» на различных ресурсах рунета (и на Хабре Гиктаймсе, в том числе) стали появляться статьи из разряда «как это снималось». Но, почему-то, все эти статьи свелись лишь к восторгам по спецэффектам (ах, Рука Фьюриосы, растудыть твою ж кочерыжку; ах, небо разукрасили, и далее в том же духе). Но «Дорога Ярости» для публики, которой уже давно приелись Трансформеры, Мстители и прочие Железные Человеки, является безбашенным экшном как раз благодаря тому что бОльшую часть фильма снимали натурально, без компьютера. Все тачки, фуры, погони, взрывы — всё было по-настоящему. Ну, чуток может и дорисовали, но именно чуток.

А вот теперь попробуйте взять видеокамеру, сесть в машину и попытаться на скорости от 60 до 160 км/час снять другую машину, едущую рядом. При езде по ровному асфальту вполне вероятно что у вас это получится, но всё равно довольно трудно будет добиться плавности картинки, чтоб не было дрожания, рывков и пропадания фокуса. А теперь представьте что съёмку вы ведёте не маленькой бытовой видеокамерой в руках, сидя в плавно едущей по асфальту машины, а большой киношной камерой (а то и сразу несколькими) из машины, несущейся по кочкам, песку и прочему бездорожью. В этой ситуации можно и не пытаться снять плавное видео «кинематографического качества».

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

Автомобиль обычно довольно приличный (порш кайен, внедорожник мерседес amg, шевроле тахо и т.д.), так как он должен уметь быстро передвигаться как по обычным дорогам, так и по бездорожью. Погони снимают на большой скорости, так что съёмочный автомобиль должен не отставать от какой-нибудь шустрой Porsche или Ford Mustang, в которой сидит какой-нибудь виндизель. А ещё автомобиль обязательно чёрный матовый, чтоб не создавать лишних бликов и не быть заметным если вдруг в удачный кадр попадёт.

Does a dog have Buddha-nature?
This is the most serious question of all.
If you answer yes or no
You lose your own Buddha-nature.

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

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

После просмотра курса Programming Languages и прочтения Functional JavaScript захотелось повторить все эти крутые штуки в python. Часть вещей получилось сделать красиво и легко, остальное вышло страшным и непригодным для использования.

Статья включает в себя:

• немного непонятных слов;
• каррирование;
• pattern matching;
• рекурсия (включая хвостовую).

Статья рассчитана на python 3.3+.

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

Про монаду ходит множество мемов и легенд. Говорят, что каждый уважающий себя программист в ходе своего функционального возмужания должен написать хотя бы один туториал про монаду — недаром на сайте языка Haskell даже ведётся специальный таймлайн для всех отважных попыток приручить этого таинственного зверя. Бывалые разработчики поговаривают также и о проклятии монад — мол, каждый, кто постигнет суть этого чудовища, начисто теряет способность кому-либо увиденное объяснить. Одни для этого вооружаются теорией категорий, другие надевают космические костюмы, но, видимо, единого способа подобраться к монадам не существует, иначе каждый программист не выдумывал бы свой собственный.

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

Именно поэтому важно если не постичь глубинную суть этого паттерна, то хотя бы научиться распознавать примеры использования монады в уже существующих, окружающих нас API. Конкретный пример всегда даёт больше, чем тысяча абстракций или сравнений. Именно такому подходу и посвящена эта статья. В ней не будет теории категорий, да и вообще какой-либо теории. Не будет оторванных от кода сравнений с объектами реального мира. Я просто приведу несколько примеров того, как монады уже используются в знакомом нам API, и постараюсь дать читателям возможность уловить основные признаки этого паттерна. В основном в статье пойдёт речь о Java, и ближе к концу, чтобы вырваться из мира legacy-ограничений, мы немного коснёмся Scala.