Помимо заработка у программирования есть бонус —  возможность выбрать интересное и необычное хобби. Например, разбирать «на запчасти» любимые видеоигры — исследовать их и переводить. Чему учит локализация старых игр,  каких навыков требует, с чего начать — об этом я расспросила программиста, который занимается подобными проектами уже 10 лет.

Игрострой конца XX века дарил нам яркие сюжеты и идеи, которым может позавидовать современная индустрия с ее канонами и ограничениями. Старые хиты были эталонами: формировали представление об игровой механике и том, какими должны быть шутеры, стратегии, RPG. Ценители расскажут вам о «теплой ламповой атмосфере» — особенно те, для кого продукция 90-х — это привет из детства.

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

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

Интервью с программистом-локализатором

Иван — профессиональный программист с 20-летним опытом. В свободное время он помогает «Бюро переводов Old-Games.Ru» русифицировать хитовые игры 80-х и 90-х годов. Если коротко, «Бюро» — энтузиасты, которые бесплатно делятся переведенными играми с человечеством.

— Как давно вы занимаетесь локализацией старых игр? С чего это началось для вас?

— Примерно в 2008 году я обнаружил исходники игры Beneath a Steel Sky и задумал перевести ее на русский язык. Я понял, что с технической стороной справлюсь сам, но для перевода текста и отрисовки шрифтов нужны помощники. В интернете нашел команду PRCA (Project of Russification of Classic Adventures) и предложил им поработать вместе. Они согласились, и я занялся извлечением текста, шрифтов, изображений. Когда уже перешел к вставке текста и шрифтов обратно в игру, у меня навернулся винт — все потерялось. Я обиделся и «забил».

Но в 2010 году вернулся к этой теме и начал работу заново. Написал инструмент для экспорта/импорта игровых ресурсов и снова обратился в PRCA, где мне рассказали о «Бюро переводов Old-Games.Ru».

— В каких еще проектах «Бюро» вы участвовали или сейчас задействованы?

— После локализации Beneath a Steel Sky я помогал с проектами:

• Lure of the Temptress;
• Alley Cat;
• Veil of Darkness;
• Crusader: No Remorse/Regret;
• Superhero League of Hoboken;
• BloodNet.

Может, еще что-то забыл. Сейчас исследую шрифт известного нуар-квеста Black Dahlia (1998).

Скриншот из игры Black Dahlia

— Чему учит программиста работа над локализацией старых игр?

— Очень быстро прокачивает скилл реверса: учит проектировать обратные алгоритмы, правильно дебажить, читать ассемблерные листинги. Об этом еще поговорим.

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

—  Из каких этапов строится работа над переводом?

— Обычный порядок действий:

1. Ищем, нет ли готовых инструментов для работы с ресурсами игры. И не вытаскивал ли их кто-то раньше.
2. Реверсим игру — «разрабатываем обратно», чтобы определить форматы хранения и сжатия шрифтов и текста.
3. Пишем инструменты для экспорта ресурсов.
4. Затем — для их сжатия и импорта.
5. Отлаживаем и поддерживаем свои инструменты.

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

— Вы сказали о готовых утилитах для редактирования ресурсов. Если они есть, зачем писать свои?

— Я ищу готовые тулзы. Если нахожу — кидаю их переводчикам, нет — создаю сам.

— Давайте о самом вкусном — о реверсе. Что это? Как это происходит?

— Реверс-инжиниринг — восстановление алгоритма работы программы. Это процесс противоположный разработке. Мы не пишем программу, которая реализует конкретный алгоритм, а восстанавливаем алгоритм по готовой программе. Для этого нужно сначала проанализировать дизассемблированный/декомпилированный или открытый исходный код. Подробнее об этом можно почитать в Википедии.

— Умение восстанавливать алгоритмы наверняка полезно и специалистам по информационной безопасности. Можно анализировать ПО и выявлять вредоносный код. А как это помогает в работе над играми?

— Чтобы извлечь ресурсы из игры, надо знать, где и в каком формате они лежат, каким образом сжаты. Лучший способ это понять — посмотреть, как сама игра достает их, отрисовывает графику и текст. Потом по восстановленному алгоритму можно писать утилиту для экспорта/импорта. Ради экономии места в DOS-играх все ресурсы обычно сжимали. Делали это разными самописными упаковщиками.

— Расскажите на примерах, как вы восстанавливали алгоритм BaSS (Beneath a Steel Sky) и других игр.

— В работе c BaSS почти все было просто. У меня был исходный код движка игры на С++ (в составе ScummVM). Я нашел в коде место, где из файлов читались шрифты, картинки и текст. Потом проанализировал, как это работает, и написал свою тулзу, которая делала то же самое.

Из сложностей там было только написание компрессора по декомпрессору. Такая задача встречается в работе практически над каждой игрой. Мы знаем алгоритм распаковки данных. Чтобы скормить игре уже отредактированные ресурсы, надо сжать их так, чтобы декомпрессор их принял «как родных» и не заметил подвоха. То есть по алгоритму распаковки нам надо спроектировать упаковку.

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

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

— Важно ли знать, на каком языке была написана игра? И как это определить?

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

— Вот вы узнали форматы сжатия и хранения. Сколько времени займет создание инструментов для экспорта/импорта?

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

— На каких языках вы пишете свои утилиты?

— Зависит от того, что установлено у переводчика, который будет моими инструментами пользоваться. В разное время я писал для «Бюро» на C#, C++, Java, ассемблере. Наши переводчики пользуются разными ОС, поэтому в последнее время больше пишу на кроссплатформенных интерпретируемых языках: Python, Ruby.

— Какие алгоритмы важно знать для написания инструментов? Используете ли вы какие-то библиотеки и фреймворки?

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

Чаще всего в DOS-играх использовали алгоритмы сжатия RLE и Хаффмана. Но встречаются и совсем уникальные. Здесь не так важно знать алгоритмы сжатия, как иметь навыки реверса.

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

— Какой софт помогает исследовать и отлаживать игру?

— Можно использовать дизассемблеры: IDA, Hopper Disassembler, Radare и другие. Для отладки подойдет DOSBox debugger. Можно еще поставить виртуальную машину QEMU с FreeDOS на ней и использовать встроенный дебаггер.

Также обратите внимание на программу ScummVM. Она включает переписанные движки старых DOS-квестов и позволяет запускать их на современных платформах, включая Linux и Mac. Добавляете игры (паки ресурсов) и можно играть. Исследовать и отлаживать ScummVM не помогает, зато позволяет смотреть открытые исходники движков.

ScummVM с запущенной Beneath a Steel Sky в переводе «Бюро»

— Вернемся к вашему текущему проекту Black Dahlia. Вы исследуете  шрифт. Что надо знать, чтобы пристроить в игру кириллицу?

— Нужно разобраться с форматом текста в игре. Я уже выяснил, как программа читает файл шрифта. Увидел, что там лежит сжатая картинка и таблица с координатами символов. Разобрал алгоритм сжатия. Дальше я напишу тулзу, которая извлечет картинку и преобразует в редактируемый PNG. Художники перерисуют шрифт, а мне останется конвертировать изображение обратно в формат игры, сжать и записать в оригинальный файл.

— С чего начать тем, у кого есть интерес и мотивация перевести игру, но нет пока опыта и знаний? На какие темы обратить внимание?

— Почитайте статьи по отладке и реверсу. Поищите исходники старых DOS-игр: посмотрите на форматы шрифтов, изображений и на то, как упакован текст. Почитайте форумы, посвященные открытым движкам и переводам старых игр. Познакомьтесь с движками, входящими в состав той же ScummVM. Загляните в git-репозиторий нашего проекта, где мы храним утилиты для разбора ресурсов старых игр.

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

—  Спасибо! Успеха Вам с Black Dahlia и другими переводами. А я еще добавлю для наших читателей несколько ссылок на статьи с описанием интересных реверс-проектов по играм.

Что почитать о реверс-инжиниринге игр

Цикл статей «Реверсим “Нейроманта”».

Devilution: проект по реверс-инжинирингу Diablo.

Извлекаем уровни из Super Mario Bros с помощью Python.

Реверс-инжиниринг визуальных новелл.

Для меня профессия «программист» всегда была окружена ореолом таинственности. Меня всегда тянуло в IT и всегда было интересно, почему они пользуются таким уважением. Я живу в маленьком городке Россошь Воронежской области. У нас мало кто знает, кто такой программист и какие еще есть профессии в IT. Я пытался общаться с приятелями и знакомыми на эту тему, но безрезультатно. Для них это неизведанная область. У всех есть телефоны, все смотрят видео, но не знают элементарных вещей. Сидим на заводе, у одного сайт на телефоне не грузится. Говорю ему: «Ты кукиз почисть». «Кукиз?» — И тишина, и все в ауте: «Что такое «кукиз»?»

Завод

В нашем городе есть АО «Минудобрения», еще с советских времен градообразующее предприятие. После кризиса 2014 г. искал работу и пошел туда. Там отец работает, все одноклассники. Работа хорошая, стабильная, но сразу понял, что это не мое. Система странно построена. Специалист, отработавший 15 лет, получает столько же, сколько недавно принятый. Руководство относится как к винтикам. Для мотивации есть только палка, не нравится — других возьмём. Завод один в городе, а людей много, вот и не ценят кадры. Пошел я на завод временно, чтобы переждать санкции. Или пока не найду работу получше. Думал, что санкции кончатся быстро, но что-то они затянулись.

Бизнес

Когда заканчивал институт в США, позвонил один знакомый и говорит, что для меня есть отличная работа. Звоню. На том конце спрашивают: «Ты знаешь английский?» Отвечаю: «Конечно, знаю. Восемь лет в Америке». Спрашивают опять: «А русский знаешь?» Отвечаю: «Конечно, я ведь русский!» Они обрадовались, я — тот, кто им нужен.

У них была проблема: не могли найти человека для работы с русскоязычными клиентами. Были или русские из России, которые плохо знают английский язык, или русские эмигранты, которые уже родной язык подзабыли. Я был посередине, и так, и так. Взяли меня сразу. Это была обычная американская компания e-commerce. Я работал в службе поддержки, писал кейсы на программное обеспечение. Я проработал два года, завоевал доверие и поехал в Россию как представитель филиала.

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

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

Америка

В Америку я попал еще студентом. В школе мы все фанатели от старой Америки. Фильмы на видеокассетах, Американская мечта, другая жизнь. Стало модным учить английский, что я и делал. Сначала в средне-специальном училище, которое закончил с красным дипломом. Затем в университете в Воронеже. Всегда хотел поехать в Америку и протестировать ее. В результате предоставился шанс.

Это случилось в 2002 году. Тогда многие ездили по программе Work&Travel. И я тоже решил поехать. Прихожу к родителям, мол так и так. В ответ слышу: «Что? Тебя обманут! Мы же простые люди, какая там еще Америка!» Насилу уговорил маму поехать со мной в Воронеж в компанию, которая отправляла студентов по программе. В офисе она сдалась. Мне вручили 2000$ из сбережений родителей и отправили с Богом. Родителей не подвел. Я брался за любую работу и обратно привез уже 4000$. Решил ехать снова. На следующее лето попал в русскую Америку во Флориду и в итоге прожил там 8 лет. Закончил бакалавриат, думал, стану доктором, но в итоге решил вернуться в Россию.

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

Портнов

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

Первым делом пошел на YouTube видео смотреть, как стать программистом. Наткнулся на Михаила Портнова. Это известный преподаватель в Силиконовой долине. Он учит русскоязычных эмигрантов тестированию. Всегда говорит, что тестирование — это задняя дверь в IT-мир. Стал думать: «Действительно, я — гуманитарий. Ну какой из меня программист?» В программировании высшая математика, а у меня в универе ее не было. И потом пришел критик в оперу. Он ни одну оперу в жизни не написал. Но он знает, как должно быть правильно, и критикует. А в тестировании как в опере. Надо не писать, надо критиковать.

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

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

Учеба

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

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

Учиться было тяжело еще и потому, что у нас маленький ребенок. А дети всегда требуют повышенного внимания. Учеба — это большая борьба самим с собой. Нужно искать мотивацию и делать. Заставлять себя эту мотивацию найти. Но сразу был момент, который очень понравился. Язык в IT — это полумикс американского и русского. Так говорят в Америке, и конечно за время жизни в Штатах я к такой речи привык. Но дома и на заводе меня плохо понимают. Приходится расшифровывать, но не всегда хочется это делать. Здесь же я могу опять разговаривать, как привык. И это норма.

Стажировка тоже принесла свои трудности. Там была командная работа. Люди все разные, мы друг друга никогда не видели. А нужно координироваться, работать с оглядкой на партнеров. Подстраиваться под них. Это был ценный опыт.

Оффер

В середине второго курса понял, что нужно прокачивать и навыки собеседования. Посмотрел Портнова. Он дает информацию, как устроиться на работу, как проходить собеседования. Из-за того, что он работает с эмигрантами, объясняет всегда так, что и бабушка поймет. Подготовился заранее и не зря. Преподаватель GeekBrains порекомендовал меня в IT-компанию.

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

Мир

Я три года отработал на заводе, где под Новый год решали, давать ли нам 13-ю зарплату или не давать, заслужили ли мы или нет. Сейчас меня все спрашивают, как я смог поступить на курсы, а потом устроиться на работу. Все думают, что нужно куда-то ехать и сидеть за партой, чтобы учиться. Но нет! Все изменилось. Современный мир заставляет меняться. Нужно понять, что перемены неизбежны и часто бывают болезненными. Лучше для себя решить, с чем ты готов расстаться, чтобы идти дальше. Кто не хочет меняться, остается за бортом.

Курсы онлайн помогают оставаться на волне. В группе было всего 5-6 человек моего возраста и старше. Остальные все — моложе. И они сразу все понимают, быстрее все схватывают. Учитывайте, что нам придется больше уделять времени учебе. Закладывайте дополнительные часы на повторение и проработку материала. Просто примите это, как особенность возраста.

Сейчас моя жизнь кардинально меняется. GeekBrains мне дал уверенность, что я смогу в 35 лет получить новую профессию и сменить направление. Обучение — это то, что дает любому человеку надежду. Идите учиться и увидите другой мир. Поймете, что все может быть по-другому, что можно жить лучше и отношение к вам будет лучше. Вас будут ценить как специалиста и человека. И это правильно.

Всем привет! Меня зовут Дмитрий. В качестве учебного проекта я сделал для Android старую игрушку Pac-Man. За два месяца ее скачали 130 тысяч раз. Меня попросили рассказать о том, как я ее сделал и почему она «выстрелила». Но пока я готовил материал, кто-то пожаловался на нарушение авторских прав, и игру забанили. Расскажу по порядку, как все было.

Предыстория

Pac-Man — учебный проект в онлайн-университете GeekUniversity, в котором я учусь с декабря прошлого года. По образованию я маркетолог, но долгое время работаю сисадмином. В технической части я самоучка, самостоятельно осваивал C#, C++, писал десктопные приложения для работы. Но разобраться в мобильной разработке сам не смог, поэтому поступил на профильный факультет.

Обучение в GeekUniversity делится на модули. Зимой я проходил курс по разработке игр. Наш преподаватель, Александр Фисунов, предложил в качестве практики самим создать старую игрушку. Из нескольких вариантов группа выбрала Pac-Man из-за   известности и простоты в реализации этой игры. Мы решили, что у нас больше шансов успеть создать ее полностью, пока идут занятия. Забегая вперед, скажу, что во время курса так и не смог доделать проект до конца. Еще понадобилась пара недель после окончания.

Реализация

В нашей   группе было 35 человек. Каждый свой проект делал сам. На занятиях обсуждали теорию и потом сравнивали, у кого какие реализации. Игру писали на Java с использованием библиотек. Я работал с libGDX. Разработка велась под десктопную версию, затем переводили в мобильную. Все ссылки на исходники выложил на GitHub.

Я немножко изменил игру. Сначала хотел сделать один в один, но мне показалось, что это будет скучно. Поэтому создал 8 карт и 4 уровня сложности, от которых   зависит скорость передвижения призраков, частота обнаружения цели, время уязвимости и восстановления.

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

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

По сути это искусственный интеллект для ботов. Мы начинаем обход карты от исходной точки. Каждая клетка получает порядковый номер шага. Таким образом, получается множество возможных маршрутов движения, один из которых приводит к цели — к «пакману». И тогда остается только пройти от цели к источнику по номерам шагов в обратном порядке и передать уже готовый маршрут боту. На GitHub лежит код алгоритма.

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

Если не хотите рисовать сами, есть множество бесплатных assets. Для текстуры пола и фруктов я использовал готовые наборы с портала OpenGameArt. Там же взял и звуки. Музыку скачал с Playonloop.

Комментарий Александра Фисунова

Во время обучения Дмитрий показал себя самостоятельным и работоспособным студентом. На курсе студенты выбрали для разработки игру Pac-Man. К последнему занятию ее основные элементы были готовы, но проект еще нельзя было назвать полноценной игрой. Необходимо было добавить контента и все отполировать, чем Дмитрий и занялся после курса. Я считаю, что у него отлично получилось и игра вышла достойной.

Публикация

Насколько мне известно, я единственный в группе, кто разместил игру в Google Play. Одногруппники сказали, что нет смысла тратить деньги на регистрацию в магазине приложений, если профита не получить. Но мне интересно было попробовать — ради опыта. Хотел пополнить портфолио первой разработкой, потому что знал, что во многих вакансиях требуют наличие приложения в Google Play. Кроме этого, проект был практически готовый. Я оплатил взнос в 25 долларов при регистрации и получил статус разработчика.

В начале загрузок было мало — скачали только друзья и знакомые. Это примерно 5–10 загрузок в день. Потом количество стало подниматься скачками и доросло до 4–5 тысяч ежедневно. По статистике, в основном игру скачивают пользователи из США, Турции и Индии, потому что весь интерфейс на английском. В России загрузок гораздо меньше, хотя есть локализованная версия.

Модерация в Google Play удивила. Сложилось ощущение, что объективности нет, и многое зависит от настроения ревьюера. Первоначальная модерация прошла без проблем. Но когда я через неделю загрузил обновление, игру заблокировали. Причиной указали рекламу «для взрослых», хотя ничего подобного там нет. После апелляционного разбирательства игру разбанили, но, как оказалось впоследствии, ненадолго.

Продвижение

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

Интересная реализация. Сейчас в Google Play примерно 80 вариантов Pac-Man. На первом месте рейтинга стоит оригинальная версия от компании Namco — такая же, как была на игровых автоматах. У нее одна карта и 256 уровней. Большое количество других «пакманов» имеют похожую реализацию: та же карта, текстура и логика. Кроме этого, в них встречается некачественная графика, баги, неудобное управление. Поэтому в основном пользователи вынуждены выбирать между классической игрой и некачественными проектами. Я разработал новую версию игры и дополнил ее картами и статистикой. Это привлекало пользователей, которые любят Pac-Man, но хотят новых вариантов.

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

Общение с пользователями. На отзывы отвечал быстро, потому что разработчик сразу получает уведомление об их добавлении. Сначала пользователи чаще всего спрашивали об управлении. Когда загрузил обновление, подобные вопросы прекратились. Еще заметил, что нет средних оценок. Пользователи ставят либо пять звезд, либо одну. Так же пишут: или «все хорошо», или «это ужасно».

Обновление. Изначально я писал игру под десктоп, поэтому логика управления движением персонажа была ориентирована под клавиатуру. Когда портировал проект на Android, не учел, что с телефона будет неудобно управлять «пакманом». В результате через неделю пришлось переделать логику и выпустить первое обновление.

Бан

Пару недель назад мои грезы о миллионах установок натолкнулись на суровую реальность. Хейтеры накидали жалоб за нарушение авторских прав, и игру заблокировали. Я получил вот такое сообщение:

В ответ подготовил апелляцию, через пару дней пришел ответ. Согласно правилам Google Play, я не имел права использовать название Pac-Man для игры.

Чтобы не словить бан, стоит пять раз подумать, прежде чем приступать к созданию продукта, связанного с зарегистрированной торговой маркой. В моем случае нужно было избегать упоминания бренда Pac-Man.

Комментарий Александра Фисунова

Причиной блокировки, как мне кажется, стало то, что проект набрал большое количество скачиваний в Play Market. Дмитрий использовал в названии известную торговую марку Pac-Man, чем и привлек внимание правообладателей. Чтобы этого избежать, необходимо было либо изменить название, либо связаться с владельцами ТМ   — BANDAI NAMCO ENTERTAINMENT INC. Но тогда для реализации требовался бы совсем другой уровень проработки проекта и целая команда разработчиков.

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

Что в итоге

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

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

В целом я доволен опытом и получившейся игрушкой. Не наступайте на мои грабли, если разрабатываете крутые версии старых аналогов. Буду рад обратной связи от сообщества GeekBrains! Если хотите покритиковать или улучшить игру, пишите в комментариях.

Прошлым летом Виктор Лоскутов поступил в GeekUniversity на факультет Android-разработки. Уже через пару месяцев он устроился программистом в компанию Wildberries. До этого работал инженером по проектированию мостов и дорог и мало что знал о разработке ПО. Мы расспросили Виктора, как повлияла на него новая работа и почему он решился искать ее с небольшим опытом в программировании.

— Чем вы сейчас занимаетесь?

— В октябре прошлого года я устроился Android-разработчиком в интернет-магазин одежды Wildberries. Работаю в Подольске, где находится склад. Все операции по перемещению вещей (упаковка, сборка, отправка заказов) происходят через терминал сбора данных (ТСД). Компания когда-то закупила ТСД на Android, поэтому ей нужны разработчики, чтобы писать софт для этой программы.

У нас небольшая команда из трех человек — два Android-разработчика и один тимлид, который по совместительству занимается базами SQL и многими другими задачами. В нашем ТСД много модулей, каждый из которых выполняет свои операции: инвентаризацию, сборку, раскладку, прием от поставщика и так далее. Таких операций много, и под каждую нужно сделать модуль. Какие-то из них простые — выполняются в одно действие. Другие — поинтереснее, посложнее.

— Почему вы отучились на инженера, а потом решили сменить профессию?

— После школы я не особо знал, чего хочу. Куда посоветовали, туда и пошел. Поступил на специальность «Строительство» на инженерном факультете в РУДН. По рекомендации друга нашел работу — она была интересной и хорошо оплачиваемой.

У нас была бригада — человек 10 и начальник. Проектирование — довольно прибыльная вещь, пока у тебя есть крупные проекты. Когда бюджет заканчивался, начальник говорил: «Мы отсюда уходим и идем в другое место на такие-то условия». Сначала мы шли на хорошие условия, потом на плохие, затем — хуже и еще хуже. Я стал задумываться, чем заниматься дальше.

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

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

— Как вы нашли работу?

— В июне прошлого года я пошел учиться на факультет Android-разработки, за компанию с другом. В тот момент я еще работал инженером-проектировщиком — проектировал мосты и эстакады. В какой-то момент с работой стало совсем туго — в сентябре я уволился, думал отдохнуть и посвятить больше времени учебе, неспешно откликался на вакансии разработчиков. Я знал, что джуниору сложно найти работу — в итоге сходил на 2–3 собеседования, после которых мне отказали.

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

— Что помогло совмещать работу и учебу?

— У меня была хорошая мотивация — очень хотелось сменить профессию. Но совмещать было тяжело: приходилось по вечерам заниматься и все выходные. Я из Подмосковья ездил на работу на электричке и там тоже постоянно смотрел уроки.

Домашние задания тоже не всегда легко делались. На первом этапе помогало то, что все было новым и интересным. Знания гораздо лучше усваивались. В самом начале мы делали на Java простенькие вещи (крестики-нолики), и они начинали тут же работать. Эти моменты были самыми прикольными. Со временем это становится обыденностью, и челленджи, которые возникают, начинают вызывать раздражение. У нас сейчас был курс по Android — там есть своя библиотека. Ее подключаешь и делаешь, и вроде все как в уроке. Но у меня ничего не работает. Там домашнее задание на 10 минут, а я просидел 2 часа. Это, конечно, бесит.

Преодолевать такие сложности можно разными способами:

• Попросить помощи у преподавателей и однокурсников;
• Если позволяет время, взять перерыв или переключиться на другую задачу;
• Если времени нет, лучше сразу расслабиться и не переживать (Акуна Матата!) — сделать как получится.

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

То что курсы в GeekUniversity — платные, помогает мне не бросить обучение, даже  устроившись работать программистом. Когда в институте учишься на бюджете, тебе все равно. А когда платишь свои деньги, сразу как-то обидно оставлять курсы непройденными.

— Что посоветуете новичкам?

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

Мне кажется, важно публиковать резюме, даже если у вас нет опыта работы программистом. В своем резюме я просто перечислил проекты, которые выполнял в GeekUniversity — выложил ссылки на GitHub. Свой предыдущий опыт работы просто кратко вписал в поле «О себе». В графу «Опыт работы» я не стал его указывать: если в резюме разработчика написать «опыт программирования — 3 месяца, опыт проектирования», это создаст путаницу.

— Что больше всего нравится в работе?

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

Все преподаватели GeekUniversity говорят: «Ребята, чтобы стать хорошим программистом, нужно просто писать код». Книжки читать — это хорошо, но реальные задачи важнее. В какой-то момент из-за всей теории в голове наступает путаница: один говорит, что вот это правильно, другой — вот это. А тебе ответить нечего, потому что ты ни то, ни другое не использовал. Когда попробуешь — поймешь, какие преимущества и недостатки у каждого из этих решений, и выберешь то, что подходит тебе.

— Какие сложности есть сейчас в работе?

— Ритм. Большая часть работы на складе выполняется круглосуточно, а значит нужно, чтобы и программы работали исправно. Если что-то где-то ломается — может понадобиться работать ночью. Буквально в эту субботу с семи вечера до часа ночи мой коллега правил ошибки, которые появились после обновления.

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

— Не жалеете, что так рано устроились на работу? Может быть, стоило еще пару четвертей в GeekUniversity закончить перед тем, как публиковать резюме?

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

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

Если есть возможность работать где-то с самого начала, нужно обязательно ей воспользоваться. Я понимаю студентов, которые боятся свой код в резюме разместить или написать, что раньше не работали программистом: «А что подумают в компании, когда они увидят мое резюме без опыта?». Но это нужно побороть, иначе так всю жизнь будешь сидеть и ждать — «вот я еще чуть-чуть доучусь, еще пять курсов пройду, тогда я точно хорошим программистом стану».

— Профессию поменяли. О чем теперь мечтаете?

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

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

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

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

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

Начните с малого и тренируйтесь «на кошках»

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

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

Пишите «от лица компьютера». Вы придумываете программу действий для машины, а не для себя. Если пишете на языке сравнительно низкого уровня (С++), «Сохранение документа» — это взгляд программиста. В языках типа Python, где код приближен к естественной речи, такая формулировка может быть понятна машине. Учитывайте это. Привыкайте смотреть на код с точки зрения компьютера, который ждет ответа на вопрос «Что делать?». В комментариях и пояснениях используйте настоящее время или повелительное наклонение: «выводим строку», «выведи строку».

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

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

Не беритесь за мелочи прежде, чем заработает алгоритм верхнего уровня. Ставьте заглушки — конечно, с условием, что вы представляете, чем их потом заменить (см. ниже пункт про бизнес-логику). В большинстве случаев идти сверху вниз не только быстрее, но и психологически проще, когда нужно мотивировать себя и не бросить начатое.

Делите код на самостоятельные блоки, которые можно проверить unit-тестированием. Иначе усложните себе поиск багов. Если участки кода, которые отвечают за конкретное поведение, не автономны — цепляются за внешний код и друг за друга — сложная структура и человеческий фактор доведут до ошибок. Работа тестировщика тоже усложнится. Вносите и тестируйте новый код небольшими кусочками, чтобы потом не запутаться в «простыне».

Посмотрите вебинар: «Быстро или медленно? Введение в анализ алгоритмов».

Не оставляйте бизнес-логику на потом

Для новичка это совет на будущее. Иногда заказчик тянет с проработкой бизнес-части, а программист уже пишет код и по своим прикидкам «оставляет место» под будущий функционал. Позже либо приходится все переписывать, либо итоговый продукт вызывает чувство стыда у всех причастных. Не начинайте работать без продуманной бизнес-логики: трясите тех, кто за это отвечает, и не пытайтесь сделать работу за них!

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

Станьте следопытом кода

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

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

Если запутались, сыграйте в настольную игру «Я — компьютер»

Правила просты:

1. Распечатываете полный листинг своей программы.
2. Отдельно распечатываете список переменных с начальными значениями.
3. Берете чистый лист — это «бумажная консоль». Не смейтесь, профессиональные разработчики иногда так играют, потому что это помогает.
4. Начинаете читать листинг с первой строки.
5. Выполняете строку кода в голове.
6. Фиксируете новые значения переменных на соответствующем листе.
7. Пишете результаты в «консоль».
8. Смотрите, ожидаем ли результат:
   1. Если нет — вы напали на след. Ищите причину несоответствия;
   2. Если да — переходите к следующей строке.
9. Повторяете пункты 5–8 до обнаружения ошибки.
10. Идете за компьютер и правите код.
11. Вы победили! Салют — ламбада — пирожок.

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

Играйте с чужим кодом

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

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

Не игнорируйте математику

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

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

Многое будет зависеть от того, какое именно ПО вы будете разрабатывать. С новыми задачами появляются и новые потребности в знаниях  — программист начинает штудировать конкретные темы. Не говорите себе «стоп-слов», а поймите, что прикладная математика — это необходимо и посильно.

Начните с вебинара «Зачем программисту нужно знать математику?».

Хуже багов в коде — только ошибки в логике программы и нашем мышлении. Сборка и запуск проходят гладко — до поры вы не подозреваете о проблеме. Но вдруг приложение начинает работать не так, как задумано. Обычно это происходит, если запустить код с непредвиденными входными данными. Результаты вычислений оказываются искаженными, или вы обнаруживаете дыры в безопасности. Ищете баг, но его нет — программа делает, что сказано. Остается вопрос: что вы не предусмотрели? Системная ошибка может потребовать переделать код полностью или почти с нуля. Застраховаться от таких неприятностей нельзя, но можно учиться на чужом опыте и обходить заведомо опасные ситуации.

Кунсткамера: «Почему это плохо работает?»

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

«Не туда положил», или неверный тип данных

Ошибка из разряда «Семен Семеныч!». Если вы неправильно выбрали тип переменной или он непредвиденно изменился во время работы кода, это может создать проблему. Например, программа попытается записать 64-битное значение в 32-разрядную переменную. Или число одинарной точности с плавающей запятой (float) попадает в переменную типа int (Integer).

У такой ситуации несколько вариантов развития:

• В языках со статической типизацией (С++, Java, С#) значения переменных проверяются на этапе компиляции. Если мы явно положили значение типа long в int, получим ошибку и шанс ее исправить. Но баг всегда найдет лазейку — в С#, например, если по итогам вычислений записать 1,7 в int, это пройдет незаметно. Причем число будет округлено до 1 и результаты дальнейших вычислений с участием переменной исказятся.
• В языках с динамической типизацией (JavaScript, Python, PHP) переменные получают значение во время работы программы. Ничто не укажет на ошибку, пока вы не столкнетесь с ней непосредственно. Неявное приведение типов в таких языках — норма жизни. Поэтому 32-битная int, если в нее поместить число с плавающей запятой, автоматически превратится во float, и никто вам об этом не скажет. Лучше еще на этапе создания алгоритма следить, чтобы у переменной не было случая самовольно обратиться «в другую веру».

Хрестоматийный пример — вещественные вычисления с целыми числами, такие как деление с остатком. Вещь настолько банальная, что в современных языках с ней просто не может что-то пойти криво… Или может.

int a = 25;
int b = 8;
float c = a/b;
Console.Write(c);
Console.Write("\n"+ c.GetType()); // Проверяем тип переменной c

Результат:

3
System.Single

На самом деле мы получили 3,125, но значение округлилось. Указание типа float для “с” не помогло сохранить точность. Компилятор сначала выполнил деление и округлил результат, а потом уже задумался о типе… и выбрал Single. Это тип, который хранит числа с плавающей запятой одиночной точности в диапазоне от -3,402823E38 до 3,402823E38. Типы float и Single — оба 32-разрядные. C# в таких случаях допускает неявное преобразование, так что компилятор не заметил подвоха.

Когда вы уверены, какой тип должен вернуться, лучше объявлять об этом явно:

float c = (float)a/b; 

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

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

Пример округления при делении int на int с остатком был актуален и для Python 2. В Python 3 это работает иначе:

a = 25
b = 8
c = a/b
print(c)
"""Проверяем тип переменной"""
print(type(c) == float)

Результат:

3.125
True

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

Вебинары GB: «Все, что вы должны знать о типах данных»  «Типы данных в PHP», «Типы данных языка C#», «Базовые типы данных, ветвление и циклы языка Java» .

Что читать: «Ликбез по типизации в языках программирования», «Статическая и динамическая типизация», «Исследование внутренних механизмов приведения типов в JavaScript», «Приведение и преобразование типов C#», «Опциональные типы данных в языке Swift».

«На волю, всех на волю!» — высвобождение ресурсов

Если вы используете язык программирования с автоматической сборкой мусора, не забывайте присматривать за высвобождением ресурсов. Большую часть времени все работает хорошо, но иногда сборщик начинает приносить больше проблем, чем пользы. Кто работал с Java, знает, что удаление отработанных данных может затянуться на неопределенный срок. Виртуальная машина ищет, какие объекты больше не нужны — в коде на них нет ссылок. Объекты попадают в очередь на уничтожение, но она может не дойти до них никогда. Хранение лишних ресурсов грузит память и создает уязвимость: среди отправленных на свалку объектов могут оставаться конфиденциальные данные.

Поэтому будьте внимательны. Можете принудительно освобождать ресурсы с помощью конструкций типа try-with-resources и try-finally. Так вы убедитесь, что все лишнее будет стерто при любом раскладе. Отпускать ресурсы на волю лучше «в естественную среду обитания» — в том же коде, где их захватили.

А еще привыкайте закрывать открытые файлы и сессии, как скобки в коде.

Что читать: «Правильно освобождаем ресурсы в Java», «Очистка неуправляемых ресурсов» (C#), «Как работает JS: управление памятью, четыре вида утечек памяти и борьба с ними».

Неслучайные случайности

На основе случайных чисел можно создавать уникальные ID для объектов и сессий, генерировать пароли, вносить разнообразие в геймплей или общение пользователя с программой. Главное, чтобы случайность не стала слишком предсказуемой. Увы, в языках программирования используют генераторы не случайных, а псевдослучайных чисел (ГПСЧ). Получить действительно случайное число не так просто. Для этого нужны внешние сигналы, последовательность которых для компьютера всегда неожиданна. Обычно в таких случаях используют аппаратуру, которая фиксирует хаотически меняющиеся параметры физического процесса. Основой рандомизации могут быть движущиеся частицы, белые шумы, микродвижения (смещение координат курсора мыши) или текущее число просмотров под самым популярным видео на YouTube (шутка). В 2017 году для получения истинно случайных чисел в МГУ специально собрали квантовый генератор.

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

Что читать/смотреть: «Подробно о генераторах случайных и псевдослучайных чисел» (с примерами уязвимостей ГПСЧ в Java и PHP), «Как написать генератор случайных чисел» (на JS), «Случайные числа и функция random» на Arduino.

Гонка за ресурсами

Если ваше приложение запускает несколько потоков, важно следить, чтобы они не конфликтовали. «Состояние гонки» — это когда потоки или процессы наперебой обращаются к общим ресурсам и нарушают целостность данных. Например, один поток увеличил значение переменной на 1, второй — обнулил, первый — сохранил. Вместо ожидаемой единицы на выходе получаем 0. Чтобы этого не происходило, нужно ставить блокировки (block), которые не позволят второму и последующим потокам работать с уже занятыми ресурсами. Либо использовать другие механизмы синхронизации: семафоры, события, критические секции. Если сказанное вам не совсем понятно, самое время разобраться в теме.

Вебинары GB: «Синтаксический сахар при работе с потоками на языке С#».

Что читать: о многопоточности, «Синхронизация процессов», «Процессы и потоки in-depth».

Публичность и «все общее»

Чтобы не было сквозняка, нужно закрывать двери, в которые никто не ходит. Так же и с объектами внутри программы: они должны быть открыты только тем участкам кода, которым действительно нужны. Это один из принципов инкапсуляции, и он важен для всех, кто применяет объектно-ориентированное программирование. «Сквозняк» в коде ведет к ошибкам во взаимодействии объектов и повышает риск перехвата данных извне. Для ограничения доступа во многих языках применяют модификаторы public, private и protected. Также избегайте использования глобальных переменных везде, где можно обойтись без них. Делиться чем-то — хорошо, но только не внутри программы, когда общий доступ к ресурсам становится источником проблем.

Что читать: «Все о модификаторах доступа» (с примерами на C#), «Модификаторы доступа и класса» в Java.

Особенности сериализации

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

Сериализацию часто используют в веб-приложениях и службах, но не только. Например, если вы разрабатываете игру на C# или Python, сериализация поможет реализовать систему сохранений.

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

Если по какой-то причине вы не хотите передавать объект в виде потока байт, есть удобные альтернативы: можно сохранить структуру объекта в формат XML или JSON.

Чтобы не писать все с нуля, можно использовать готовые классы-сериализаторы:

• BinaryFormatter — обеспечивает бинарную (двоичную) сериализацию, т.е. преобразование в поток байт;
• SoapFormatter — сериализует связанные объекты в SOAP-сообщение: особым образом структурированный XML-документ, который пересылают по протоколам HTTP, HTTPS, SMTP и другим;
• Xstream — Java-класс для сериализации в XML и JSON-файлы. XML весит меньше SOAP и быстрее передается по сети, но не так гибок в описании типов данных. Данные формата JSON являются объектами JavaScript и удобны для использования в клиент-серверных приложениях.

Что читать: «Как не наступить на грабли, работая с сериализацией», «Сериализация (C#)», «Сериализация объектов PHP», «Обобщенное копирование связных графов объектов в C# и нюансы их сериализации».

С-библиотеки без присмотра и переполнение буфера

Есть мнение, что в языках более высокого, чем С, уровня (Java, Python, C#, Rust) проблема переполнения буфера решена. Например, Java по умолчанию контролирует размер буфера и границы массивов. Но для ускорения жадных к ресурсам участков кода многие программисты используют С-библиотеки. И вот здесь будьте осторожны. Языки С и С++ считаются сложными именно потому, что дают простор для ошибок, которые легко допустить, но трудно найти. В плане переполнения буфера код на C/С++ очень уязвим.

В чем суть проблемы? Если неправильно рассчитать или не проверить размер буфера, программа попытается записать данные за его пределами. Это не только ошибка, но и дыра в безопасности. Злоумышленники могут намеренно переполнить буфер, чтобы подменить хранимый в стеке адрес возврата, т.е. адрес функции, которую надо вызвать по завершении текущей. Подставная функция передаст дальнейшее управление мошенническому коду. Такой подход используется при создании вирусов с 1988 года. Чтобы не наступить на ржавые 30-летние грабли, узнайте больше о том, как бороться с переполнением буфера.

Что читать: «Как устроены дыры в безопасности: переполнение буфера» (или оригинал на английском).

Переменные впрок

Иногда начало кода у новичка выглядит как выставка достижений народного хозяйства. Там объявлены не только переменные и константы, необходимые сразу после запуска программы, но и те, которые потребуются намного позже или не нужны вовсе. Это говорит о пренебрежении инкапсуляцией и плохом планировании еще на этапе создания алгоритма. Разработчик не знает, где объявлять переменные в разных случаях, и складывает все «в коридоре».

Вносите в алгоритм только то, что готовы инициализировать!

Хотите на таком-то этапе присвоить вот этой переменной вот это значение? Так и пишите. Что-то переиграли? Не забудьте почистить код.

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

Что читать: «Переменные» (и где их объявляют — на примере С++), «Области видимости и замыкания в JavaScript».

Как найти остальные ошибки?

Читайте вторую часть статьи — она познакомит вас с инструментами и методами поиска логических ошибок в алгоритме и коде программы.

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

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

В программировании есть области, где преобладает ежедневная рутина. Задачи специалиста, который создает базы данных, могут отличаться количеством таблиц, сложностью, объемом, но не смыслом. Он всегда один: разработать хорошую БД, которая будет справляться с большой нагрузкой.

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

Вот 6 сфер, где работают программисты (а вы и не догадывались).

Медицина

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

Представляете установку искусственного кровообращения? Взгляните на структурную схему аппарата ИВЛ «Фаза-5-01»:

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

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

Космос

А космос? Невозможно представить, чтобы ракета полетела «сама по себе»: без датчиков, алгоритмов обработки траектории полета. Без программистов не обойтись.

Пример — инновации компании «SpaceX». Теперь ступени и блоки ракеты не падают в море и не летают на орбите Земли космическим мусором, а могут сесть обратно и использоваться повторно. Только подумайте, сколько информации нужно обработать, чтобы благополучно приземлить ракету.

Уже горите желанием работать в такой корпорации, как «SpaceX»? Тогда прислушайтесь к словам члена команды полётного ПО Алексея Пахунова: вы должны уметь писать надежный код на C++ и понимать, как работает компьютер на разных уровнях.

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

Музыка

«А если я люблю музыку?», — спросите вы. Сегодня и её создают и обрабатывают в специальных программах.

В их числе — «Pro Tools», написанная на C, C++ и языке ассемблера, которую используют практически все профессиональные звукозаписывающие студии. «Antares Autotune» применяется для «шлифовки» голоса — программа исправляет неточности в нотах. Артисты, которым теперь не надо многократно переписывать один и тот же участок песни, вздохнули с облегчением.

Неожиданная сфера? Еще бы, и невероятно интересная для любителей чистого звука и ритма.

Искусственный интеллект и машинное обучение

Музыка, медицина — старо, как мир. А что из инноваций? Активно развивается направление искусственного интеллекта и машинного обучения. К этой сфере относится и разработка игр, и сравнительно новая отрасль автомобилестроения — создание беспилотных машин.

Если вы увлекаетесь игровой индустрией, то не пропустили событие 2017 года, когда стало понятно, что технологии машинного обучения уже на порядок превосходят возможности человека. Бот OpenAI победил в игре «Dota2» лучших игроков планеты, сражаясь один на один. Все благодаря тому, что он долго играл, анализировал и запоминал действия участников. В июне бот не мог справиться даже с противником, одиночный рейтинг которого составлял 1500, а через месяц — выиграл партию у полупрофессионального игрока с 7500 MMR. Невероятная скорость самообучения!

Что касается беспилотников: автомобили компании Uber преодолели уже более 3 миллионов километров в автономном режиме.

Виртуальная и дополненная реальность

Голограммы размером с небоскреб мы видим в фантастических фильмах. Но так ли далеко будущее? С нынешними темпами развития виртуальной реальности подобное мы сможем наблюдать уже в ближайшее десятилетие. У вас есть все шансы принять участие в создании и развитии технологии!

Уже сейчас дополненная реальность используется «в быту». IKEA предлагает клиентам «примерить» мебель к своей комнате до покупки — с помощью мобильного приложения. Просто скачиваете его с App Store или GooglePlay, выбираете интересующий товар и в режиме реального времени смотрите, как новый диван будет выглядеть у противоположной стены или у окна. И все это работает благодаря программистам.

Блокчейн и распределенные реестры

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

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

С такой динамикой развития сферы уже в ближайшем будущем спрос на блокчейн-специалистов будет огромным. А предложение — небольшим. По логике, должность должна стать высокооплачиваемой. Только в России за 2017 год было размещено порядка 500 вакансий для блокчейн-специалистов со средней зарплатой в диапазоне от 200 000 до 400 000 рублей.

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

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

Программисту — познайте чистую архитектуру

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

Что почитать. Автор бестселлеров «Чистый код» и «Идеальный программист» Роберт Мартин выпустил новую книгу «Чистая архитектура. Искусство разработки программного обеспечения». «Чистая архитектура» — фундаментальный труд, который рассматривает парадигмы, принципы и компоненты. Издание будет полезно как начинающим программистам, так и кодерам с опытом. Дядюшка Боб дает системное понимание, с чего начать, какими принципами руководствоваться и как должен выглядеть идеальный вариант.

Что посмотреть. Послушайте выступления самого Дядюшки Боба: Чистый код, Принципы чистой архитектуры, SOLID. Тем, кто хочет видео покороче, предлагаем выступление Марка Бастьяна про правила проектирования.

Что попробовать. Поработайте над новым или текущим проектом с применением новых знаний. Попробуйте продумать архитектуру, ответив себе на три вопроса: «Что мы делаем?», «Зачем?» и «Как?». Возьмите лист бумаги и посидите часок, размышляя о превратностях судьбы и проектировании архитектуры. Попробуйте получить результат.

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

Веб-разработчику — создайте Progressive Web Apps

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

Что почитать. Изучите руководство Google для создания PWA — веб-приложения, которое работает как мобильное. Его можно запустить для любого сайта, но для этого не нужно знать язык мобильной разработки. Стека HTML & CSS & JavaScript  будет достаточно.

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

Progressive Web Apps: What, Why, and How?

From Website to Progressive Web App

Frameworks and Tools for Progressive Web Apps

PWA+AMP

Что попробовать. Познакомьтесь с технологией и создайте PWA для своего сайта или заказчика. Проверьте PWA через расширение Chrome Lighthouse. Поделитесь полученным с миром: опубликуйте результат на GitHUB, а в комментариях кидайте ссылку.

Как развлечься. Вы же знаете, что в мире создаются не только сайты про пластиковые окна и блоги адаптивных веб-мастеров? Посетите странные и забавные интернет-ресурсы, может быть после PWA вы тоже создадите funny-сайт.

Рычащая кнопка

Виртуальное пианино

Цветочек или птичка?

Млечный путь

Медитация под полосочки

Бесконечные шары

Цветная бумага

Дизайнеру — визуализируйте

Почему важно. Информация делится на вербальную (10%) и визуальную (90%), но очень часто мы об этом забываем и пытаемся объяснить, научить и рассказать с помощью слов. Однако восприятие через рисунок будет намного проще и действенней.

Что почитать. Советуем обратить внимание на книгу Дэна Роэма «Рисуй, чтобы победить». Книга Дэна по сути иллюстрированный курс, который позволит по-новому взглянуть на процесс представления информации. Сам Дэн научился этому в начале 90-х в России, когда пытался коммуницировать без знания русского языка. Он — признанный лидер в области визуального представления информации. В 2009 г. его презентация системы здравоохранения в США на четырех салфетках была признана лучшей презентацией года. Если вы тоже хотите убеждать окружающих с помощью рисунка на салфетке, эта книга для вас.

Что посмотреть. Посмотрите вебинары, лекции и работы, посвященные визуализации, UХ-дизайну и методам предоставления информации.

UX-дизайн для начинающих

The beauty of data visualization

Легендарный Тафти

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

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

Маркетологу — продвиньтесь в топ

Почему важно. Поисковые алгоритмы меняются ежемесячно, чтобы ранжировать сайты эффективнее. Методы SEO меняются вслед за ними. Без знаний поискового продвижения оказаться в топе практически невозможно. Даже когда ресурс просто бомба по удобству и контенту, его не пропустят на верхние строчки сайты с правильным seo. Чтобы пробиться, придется оптимизировать сайт и играть по правилам поисковиков.

Что почитать. Почитайте англоязычный блог на ресурсе MOZ — экспертном портале, посвященном seo и маркетингу в мире. Сооснователь Рэнд Фишкин регулярно раскрывает секреты выхода в топ в видеороликах, поэтому здесь можно и почитать, и посмотреть. Здесь вы найдете все о продвижении в Гугл и западных технологиях. Яндекс ведет свой блог для вебмастеров, в котором рассказывает, как сделать сайт лучше, чтобы он попал на первую страницу поиска.

Что посмотреть. На портале GeekBrains мы подготовили ряд вебинаров на тему поисковой оптимизации. Мы рассмотрели структуру сайта и как ее проектировать, узнали, какие слова важны для seo и где их находить. Разобрали must have инструменты для seo-оптимизатора и определились, нужны нашему сайту ссылки или нет. Смотрите вебинары в записи, если будут вопросы, задавайте на форуме:

Ключевые составляющие SEO-оптимизации

Ключевые составляющие SEO оптимизации. Часть 2

Что попробовать. Попробуйте собрать семантическое ядро для сайта. Для этого воспользуйтесь бесплатным инструментом Wordstat.Yandex. Составьте на основе ядра структуру будущего ресурса. Подумайте, на основе каких слов сделать большие разделы, а какие ключи оставить для написания статей. Потренируйтесь в написании title, description и h1. Затем найдите ресурс похожей тематики в топе поисковой выдачи и сравните его с вашим вариантом оптимизации.

Как развлечься. Почитайте исследования Яндекса. Поисковик регулярно анализирует поисковые запросы пользователей и выкладывает отчеты, из которых можно узнать много интересного. Например, какие картинки ищут чаще всего, куда ездят на такси или что ищут на Яндекс.Картах. В завершении пройдите тест «Что ищут чаще?». Как вы думаете, нефть или биткоин?

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