Привет, Хабр!

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

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

Сегодня мы публикуем перевод заметки «Почему программировать так тяжело?». Тем, кто еще изучает основы программирования и разработки будет полезно узнать, что их ждет в будущем. А опытным разработчикам будет просто приятно взглянуть на реальность и покивать головой.



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

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

«Бог всегда на стороне больших батальонов» — Жак д'Эстамп дела Ферте, французский маршал

Рис. 1

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

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

Привет всем хаброюзерам. Хотел бы поделиться опытом создания нативных расширений для OS X.

AIR — просто потрясающая в своей кроссплатформенности среда. Пока дело не доходит до использования каких-то уникальных для платформы фишек. Именно с этой проблемой я столкнулся, когда передо мной была поставлена задача превратить браузерную flash-игру в десктопную для OS X. Всё это с использованием среды AIR мной было сделано за несколько часов и я не буду описывать этот процесс, так как в гугле на эту тему полно информации. Самое интересное началось тогда, когда появилась необходимость подключить к игре различные сервисы Apple, такие как GameCenter, In-App-Purchase и т.д. И здесь я столкнулся с трудностями. Дело в том, что есть куча готовых ANE, в том числе и бесплатных. Но вся беда в том, что все эти решения работают только для iOS. Для OS X же нет ни то, что готовых библиотек, но даже информацию по созданию этих библиотек приходилось собирать по крупицам с пары-тройки интернет ресурсов многолетней давности, постоянно натыкаясь на какие-то подводные камни или даже айсберги.

Сейчас же я хочу собрать все накопленные знания и опыт в одном месте и поделиться с вами, чтобы хоть немного уменьшить ту боль, через которую вам придётся пройти, если всё таки вы тоже решитесь на создание нативных библиотек для мака. Хотя после четырёх разработанных расширений для OS X они не кажутся такими уж сложными и мудрёными.

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

Привет, Хабр! Продолжаем серию статей об архитектурном дизайне мобильных приложений. Под катом поговорим о проектировании слоёв UI. Добро пожаловать!

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

Исследование, проведенное Software Engineering Institute, показывает, что программисты делают 15-20 распространенных ошибок. Добавив такие ошибки в чеклист, вы можете быть уверены, что заметите их в момент появления и поможете от них избавиться надолго.

Чтобы вам было от чего отталкиваться, вот вам список типичных пунктов:

Эта тема не относится к IT напрямую, но все знают, что без нее никуда. К сожалению, далеко не у всех есть возможность изучать английский с преподавателями. Ну что ж, попробуем заняться этим дома и с максимальной отдачей!

Понедельник начинается в субботу.
А. Стругацкий, Б. Стругацкий.

Прошедшее забыто, грядущее сокрыто, настоящее даровано. Поэтому его и зовут настоящим!
Мудрая Черепаха из «Кунг-фу Панда»

Сегодня пойдет речь о методе, который я применяю, когда уматывают планы и лениво что-то делать вообще. Я знаю, есть люди, не любящие планирование. Есть люди, которые не любят загадывать. Есть те, кому просто непонятно, как работает его организм. Во всех этих состояниях я бывал, делюсь опытом.

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

Под катом простая схема, как этого достичь.

Перевод статьи "Game a Week: Year In Review" о том, как Adriel Wallick весь предыдущий год делала (или старалась делать) по одной игре в неделю.

Я начинала проект «Игра за неделю» для того, чтобы найти мотивацию.

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

Вот так и был «рождён» срок в неделю, и я начала делать игры, придерживаясь этого ограничения.

Лучший способ научиться чему-то — это научить другого.

Наступил январь, студенты начинают сдавать экзамены. И часто самым сложным экзаменом оказывается математика. Мой хороший друг спросил у меня: «Что такое теорема Лагранжа, как её доказать и понять?»

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

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



Мы всегда даём хорошие советы, но, как Алиса в стране чудес, следуем им нечасто. Это происходит, потому что мы торопимся, мы создали себе шаблоны поведения, и не задумываемся над тем, чем мы занимаемся.

Иногда я придумываю себе задачки, и пытаюсь их решить. Вот, например, одна из них:

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

Подумайте, как решить эту задачу? Как бы эту задачу решил умный человек?

Привет, хабражители!

Представляю вам список YouTube-каналов для обучения веб-разработке. Список доступен на гитхабе, там он будет пополняться и редактироваться. В планах — создание отдельной странички для фильтрации каналов по тегам и рубрикам.

Также хочу попросить вас о небольшой услуге: если вы знаете канал, не вошедший в список — опубликуйте ссылку на него в комментариях или отправьте pull request. Сообщество будет благодарно вам.

Под катом — текущая версия списка.

… в общем создал я игру. А дело было так.

Несколько месяцев назад подошёл мой начальник и обрадовал, что с сегодняшнего дня, в дополнение к своим основным обязанностям, я должен буду делать iOS-приложения (не сильно сложные, но по работе необходимые), что Mac mini мне купили и что я самый опытный из всех по части продукции Apple (это правда, т.к. ваш скромный слуга уже четвёртый год ходит с 1-м iPad). Ну ладно.

Давным давно (летом 2014), когда я усиленно работал с оформлением, передо мной возникла следующая проблема. Я хотел использовать CSS3 для создания эффекта прыгающего мячика с учетом естественных законов физики. Я прошерстил Интернет в поисках какого-нибудь способа, чтобы «вдохнуть» гравитацию в мой мячик.

После нескольких часов просматривания Stackoverflow и доков CSS, я нашел несколько опций, но это все равно не до конца меня устроило. Использование Javascript и Jquery было бы лишним и неэффективным для такой простой задачи, которая, как кажется, должна легко решаться с использованием существующих опций для анимации в CSS3.

Я сначала попытался использовать переходы ease-in (ease-out), которые представлены CSS. Но несмотря на то, что они выглядели достаточно плавными, было слишком сложно добиться ощущения естественности. И каждый новый прыгающий объект нуждался бы в совершенно новой функции, подобрать которую очень трудоёмко. Многие сайты, которые я посещал, предлагали использовать громоздкие keyframe-функции для описания анимации каждого прыжка. Код этих функций выглядит слишком сложным и избыточным. Более того, полученные прыжки объекта выглядели отрывистыми и непрофессиональными.

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

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

последняя редакция статьи доступна на сайте makeloft.xyz

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

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

Идея отметить День космонавтики-2012 просмотром фильмов на эту тему привела к тому, что я серьезно заинтересовался историей космонавтики. И тут оказалась к месту игра, о которой я знал, но не интересовался достаточно, чтобы ознакомиться. Она вышла в 1993 году и называлась тогда Buzz Aldrin's Race Into Space. Легендарный астронавт Базз Олдрин принимал участие в её разработке как технический консультант. В 2005 году разработчики выкупили права и перевыпустили игру под лицензией GPL, убрав имя Олдрина. Игра очень интересная и всячески рекомендуется к ознакомлению, однако, спустя некоторое время, мне стали очевидны моменты, в которых игру можно улучшить. Так появился Open Source проект Space Race: The Game. Рассказом о нём и тех улучшениях, которые запланированы, я и хочу с вами поделиться под катом.

Ранее мы уже знакомили вас с переводами статей Chris Bailey, которые он писал по мере развития своего проекта a Year of Productivity — они доступны в нашем блоге в разделе «личная продуктивность».

Сегодня мы хотели бы познакомить вас с выводами Криса о взаимосвязи между продуктивностью и счастьем.

Итак, даем слово Крису!

Лет пять назад в моей жизни наметилась неприятная закономерность: я стал замечать, что процент выполнения «целей на год» год от года уменьшался, и достиг в итоге катастрофической отметки в районе 12%. При этом у меня абсолютно не было ощущения провального года, поэтому я начал подозревать что что-то не так. В результате несколько лет экспериментировал с постановкой целей, попутно изучая теорию и дискутируя с GKh. В результате мне удалось сформулировать способы постановки целей, максимизирующие вероятность их невыполнения – и хочу поделиться этим знанием с вами.

Сколько часов в неделю вы тратите на работу? Около 40, не так ли? А как вы думаете, что будет, если работать 90 часов в неделю?

Автор сайта a Year of Productivity Chris Bailey решил провести такой эксперимент. К чему это привело? Читайте о 10 уроках, которые он извлек, в нашем переводе его статьи.

Картотека – старый инструмент для генерации новых идей



Среди инструментов работы с информацией и развития творческого мышления одним из самых годных для меня оказалась весьма архаичная штука. Самое универсальное и четкое описание этого инструмента я встречал у гуру отечественного тайм-менеджмента, товарища Глеба Архангельского, но сама идея мелькает в ноосфере то здесь, то там, начиная, наверное, с писателей еще века 18-го. Называется он (у Архангельского) творческой картотекой.

Идея, сама по себе, проста и интуитивно понятна. Суть: сделать этакую кормушку для подсознания, его «раскачки» на выработку креативных идей по нужной теме, а заодно – реализовать один из базовых принципов GTD, согласно которому все должно оперативно фиксироваться где-то на внешнем носителе и выкидываться из головы. Механизм: записываешь удачные идеи на отдельные карточки и впоследствии периодически эдак медитативно перебираешь их. Всё.

Теперь подробнее

Если у вас есть некий процесс, который может выполняться долго и возвращать несколько промежуточных результатов с течением времени, то Реактивные Расширения (.NET Framework Reactive Extensions) позволят вам упростить код и лучше управлять им.



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

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