Первая часть короткого и жесткого введения в Haskell. Вторую часть можно найти здесь

tl;dr: Очень краткое и сжатое введение в Haskell.

• Введение
  
  • Установка
  • Без паники
  • Самые основы Haskell
    
    • Объявление функций
    • Пример использование типов
    
    
  
  
• Необходимый минимум из Haskell
  
  • Выражения
    
    • Арифметические
    • Логические
    • Возведение в степень
    • Списки
    • Строки
    • Кортежи
    • Разбираемся со скобками
    
    
  • Полезные вещи для записи функций
  
  
• Сложная часть
  
  • Функциональный стиль
    
    • Функции высшего порядка
    
    
  • Типы
    
    • Вывод типов
    • Создание новых типов
    • Рекурсивные типы
    • Деревья
    
    
  • Бесконечные структуры
  
  

UPD. Если туториал вам понравился, черкните пару строк автору оригинальной статьи. Человеку будет приятно ;)

Приветствую достопочтеннейших Хабралюдей!


Не так давно, во время поиска новой работы, я получил очень интересное тестовое задание от ZeptoLab: написать за пару рабочих дней арканоид под iOS без использования сторонних библиотек типа Cocos2d/Box2d и т.п., то есть, на «чистом» OpenGL, что показалось мне весьма интересным. Кстати, об этом задании на Хабре уже писали, и даже устраивали разбор полётов. Итак, я бросил вызов судьбе и взялся за геймдев впервые после школьных упражнений с васиком в графическом режиме!

Уточню, что некоторые знания OpenGL у меня уже были, но весьма и весьма поверхностные. Можно сказать, что их не было ну почти совсем, я просто знал, что такое вьюпорт и что бывают какие-то там спрайты, что существуют матрицы преобразования… Так что данная статья могла бы быть озаглавлена "Как написать простую игру под iOS на чистом OpenGL, не зная его", но это слишком уж длинно.

В общем, если Вам интересно, как я это сделал за ~10 часов разработки и ~2 часа чтения, прошу под кат. (осторожно! много кода! мало картинок! ссылка на гитхаб и расслабляющее видео в конце!)

Широко известны сайты для решения олимпиадных задач по программированию, такие, как, например, TopCoder и Codeforces, а также сборники математических задач-головоломок, например, Project Euler. За последний год произошёл бум онлайн образования: возникли стартапы Coursera и Udacity, предоставляющие онлайн курсы от топовых университетов США… но для тех, кто хочет изучить биоинформатику, пока ничего нет.

Розалинд — проект, разрабатываемый в Санкт-Петербуге и University of California, San Diego с мая 2012 года, как раз заполняет эту нишу. Это платформа для обучения биоинформатике с помощью решения задач, бесплатная и открытая.

Недавно я прочитал о том, что Гэйб Ньюэлл всерьёз настроен на то, чтобы перенести хорошие и качественные игры в Linux. Как он считает, это именно то, чего не хватает, и что на данный момент ограничивает развитие платформы. Безусловно, он прав. Тем не менее, лично для меня есть и другая область, которая мне даже намного важнее, чем игры — это музыка. Если без игр я могу обойтись, то музыка для меня необходима — как, впрочем, и для многих других людей.


На картинке ­— рабочее место Niels Ott, на компьютере запущен Ardour.

Моя жена тоже музыкант, и когда она увидела, какие секвенсоры и синтезаторы есть в Linux — она даже не стала пытаться в них разобраться, просто вернувшись к своим Cubase и Reason. На её ноутбуке есть Windows 7, и когда она пишет музыку, она просто перезагружается туда и запускает там эти программы.

Я же, пользуясь Linux уже около 10 лет, не могу так просто отказаться от того, чтобы хотя бы пробовать имеющиеся программы. В принципе, могу точно сказать, что за 10 лет всё очень сильно изменилось в лучшую сторону. И всё же то, что сейчас есть под Linux для написания музыки, очень далеко от идеала. Давайте вместе разберёмся, почему бо́льшую часть музыки всё ещё пишут на Mac OS X или Windows.

От переводчика: я наткнулся на эту статью случайно, когда искал информацию по управлению загрузкой символов во время отладки. И хотя по этому вопросу информации было не так много, я с удовольствием прочитал всю статью. Большая часть были мне известна и до этого, но не всё. Уверен, что многие найдут в ней для себя что-то полезное. Статья написана полтора года назад, однако не все переходят на новые версии студии и сопутствующих инструментов сразу после их появления, так что актуальности статья не потеряла.

Javascript Enlightenment

Cody Lindley

Уровень знаний: средний
Тщательный обзор мировоззрения JavaScript через разбор встроенных объектов и нюансов.

Открыть

Eloquent Javascript

Marijn Haverbeke

Уровень знаний: начинающий
Вводная книга по JavaScript и программирование в целом.
Открыть

Building A JavaScript Framework

Alex Young

Уровень знаний: продвинутый
Избранные статьи из цикла«Let’s Make a Framework».
Открыть

В предисловии к первому изданию замечательной книги «Структура и Интерпретация Компьютерных Программ» (SICP) авторов Харольда Абельсона и Джеральда Джей Сассмана, есть цитата из статьи Марвина Минский «Почему программирование — хороший способ выражения малопонятных и туманно сформулированных идей.» Цитата короткая, а полная публикация на русском языке мне не попадалась.
Ниже вы можете ознакомится с переводом этой статьи, и хотя написана она довольно давно, всё равно интересно ознакомится с мыслями такого человека как Марвин Минский, оригинальную статью можно найти здесь.

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

Преамбула

В конце лета прошлого года мы решили сделать продолжение нашей игры Папа Пингвин как полноценную новую игру. Вначале мы хотели лишь слегка изменить имеющуюся идею и выпустить на основе нее более серьезный проект, использующий наши наработки, однако мы недостаточно основательно подошли к вопросам препродакшена и не определили достаточно четко фокус и базовый геймплей проекта с самого начала. В результате игра получилась не такой лаконичной и цельной, как могла бы, а разработка игры затянулась. Причем не все запланированные фичи были реализованы, а в процессе разработки приходилось несколько раз останавливаться, пересматривать полученные результаты и упрощать как саму идею, так и дизайн уровней, интерфейс и т.д. Последние упрощения были сделаны после проведенных тестов и отзывов. В итоге получился именно Капитан Антарктика, а не Папа Пингвин 2. Результатом, откровенно говоря, я не совсем доволен. Хотя игра получилась очень интересной, многое в ней можно упростить и улучшить (что мы и постараемся сделать в ближайших обновлениях).

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

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

Недавно в моей RSS ленте сразу несколько людей написало о большой подборке всяких штук для AS3, которые могут изрядно упростить жизнь Flash-разработчикам. Одним из таких людей был injun (чей блог я читаю уже очень давно), в его посте я увидел ссылку на исходный пост одного зарубежного автора, и решил сам посмотреть, что там к чему.

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

Нашей компании уже 6 лет. Она была основана на принципах agile и росла на них. Мы использовали Extreme Programming с самого первого дня, добавили немного Scrum позже и в конце концов переключились на Kanban. Хочется поделиться бесценным опытом и рассказать об изменениях нашего процесса разработки за последние 4 года.

Меня время от времени озадачивают вопросами в связи с мимолётной заметкой, которую я сделал в 2010, по поводу того, что я больше не программирую ради заработка. Это правда. Я не работал в качестве full-time программиста с 2003-го. Короткая версия этих вопросов — «Почему?». Более длинная версия — «Слушай, ты ведёшь супер-технический блог о программировании и, похоже, ты знаешь все эти штучки, но неужели ты не хочешь работать программистом?».

Автор оригинальной статьи — Майкл Эбраш, человек и пароход. Для тех, кому лень изучать википедию, отмечу, что это программист с более чем 30-летним стажем работы, который в свое время помог Кармаку сделать Quake, разработал GDI для Windows NT, приложил руку к созданию первых двух версий Xbox, а сейчас работает в R&D-отделе компании Valve.
В своей заметке он вспоминает, как зарождалась индустрия 3D-игр вообще и Valve в частности, рассказывает про свой опыт работы в различных корпорациях, приоткрывает завесу внутренней кухни Valve и ищет новых сотрудников. Статья большая, и я посчитал ее достаточно интересной для того, чтобы перевести на хабр.

---

Всё началось с Лавины*.

Если бы я не прочел её и не влюбился в идею Метавселенной, если бы она не заставила меня представить, насколько распределенная 3D сеть близка к воплощению в жизнь, если бы я не подумал я могу сделать это и, что более важно, я хочу сделать это, я бы никогда не встал на путь, который в конечном счете привел меня в Valve.

В 1994 году я уже несколько лет как работал на Microsoft. Однажды вечером, когда моя дочка рассматривала книги в магазине Little Professor в Sammamish Plateau, мне посчастливилось заметить Лавину на полке. Я взял книжку, прочитал первые страницы, решил купить и в итоге проглотил её за день. Параллельно я начал задумываться о том, что 80 процентов описанного в ней осуществимо прямо сейчас, и мне захотелось реализовать это сильнее, чем когда-либо вообще хотелось сделать что-то с компьютером — я всю жизнь читал научную фантастику, и вдруг мне выпал шанс превратить её в реальность. Так я попытался начать в Microsoft проект по созданию технологии сетевого 3D.

В последнее время словосочетание «машинное обучение» (Machine Learning, ML) стало невероятно модным. Подобно любой распиаренной технологии, энтузиазм здесь превосходит уровень реализации конкретных продуктов. Можно спорить, но мало какие алгоритмические технологии со времен потрясающих инноваций от Google 10-15 лет назад привели к появлению продуктов, широко распространившихся в массовой культуре. Не то, чтобы с тех пор не было прорывов в машинном обучении, не было столь потрясших и имевших в основе вычислительные алгоритмы. Netflix может использовать умные рекомендации, но он и без этого Netflix. А вот если бы Брин и Пейдж не анализировали в своих корыстных целях графовую структуру веба и гиперссылки, у нас не было бы Google.

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

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

Видеоматериалы

В одной из своих статей Бьёрн Страуструп (папа С++) признался, что он не признает видео материалы в качестве источника для самообразования. И с ним сложно не согласиться, когда речь касается изучения с нуля языка программирования или технологии. Я правда сомневаюсь, что можно одолеть такого монстра, как С++ или стать гуру WPF лежа на диване и просматривая обучающее видео типа «Узнай все за 24 часа». Но если вы ставите себе цель познакомиться с некоторой технологией или новой возможностью языка программирования, или просто послушать философско-компьютерные размышления умного товарища, то в этом случае веб-касты, записи конференций или другой вид видеоматериалов может быть очень кстати.

Чуть более двух лет назад я опубликовал статью Другое видение скучных GTD планировщиков через призму RPG игр, в которой описал свою старую идею про совмещение работы над software проектами и элементов RPG игр.

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

Топик тогда собрал 100500 комментов (в основном «супер! хочу!»), а особо заразительные собрались в команды и стали воплощать идею в жизнь. Так что же было сделано за эти два года?

Доброго времени суток. Это статья — перевод заинтересовавшего меня поста в блоге аспиранта Университета штата Нью-Йорк в Стоуни-Брук. Статья в доступной форме описывает основные концепции функционального программирования, их преимущества и недостатки. Думаю она будет полезна широкому кругу читателей, которые сомневаются, нужно ли им углубляться в мир функционального программирования или нет. Пожелания, предложения и замечания по переводу и терминологии принимаются по личной почте.

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

UPD: альтернативный вариант перевода вы можете найти на rsdn (спасибо flamingo за ссылку).

Эта статья является продолжением предыдущей и второй из общей серии биографий. На этот раз я рассмотрел несколько фамилий, которые более известны среди любителей JS.

В любой профессии есть тонкая прослойка людей, которые являются действительно высококлассными специалистами. Не исключение и область фронт-енд разработки — здесь также есть выдающиеся личности. К их мнению прислушиваются, за ними следят в блогах и социальных сетях и читают их книги. В процессе своей работы они рождают различные оригинальные решения или техники, которые мгновенно расходятся по миру веб-разработки и остаются актуальными не один год. Они создают удобные онлайн-сервисы для верстки, пишут полезные js-библиотеки, совершенствуют браузеры, пропагандируют веб-стандарты и оказывают непосредственное влияние на их развитие. Они могут называть себя front end engineer, front-end developer, web developer, web designer, UI Designer, browser compatibility expert или просто css lover, но для большинства из нас они — звезды мирового фронт-енда, которые делают интернет таким, каким мы его знаем. На Хабре довольно часто появляются обзоры интересных решений, техник и новостей из мира веб-разработки с указанием западных авторов, однако далеко не все знают что-нибудь о них кроме имени. Мне захотелось вкратце рассказать для широкой публики о некоторых из этих товарищей.