воскресенье, 19 февраля 2017 г.

Ретроспектива - часть 4 - Первый GameDev

Один из вопросов который мне задали на собеседовании, это на каком месте на ladder’е я был в Starcraft. А также немного поспрашивали по тестовому, реализацию которого на тот момент я считал идеальной. Намекнули мне, что по зарплате я хочу больше чем остальные. Вообще после, я много раз слышал,  что на собеседованиях говорят, что я действительно хочу большую зарплату. Но всё таки основываясь на рынке вряд ли она такая уж и большая.
Как-то раз, собеседование прошло просто ужасно с моей стороны, я завалил все вопросы, которые только можно было. И в тот момент, я понял, что мои зарплатные хотелки будут выглядеть сейчас для моего собеседника просто верхом наглости. И я нарочно снизил планку, до минимума. Более чем в два раза меньше, чем от среднерыночной зарплаты. И что я услышал? Что я хочу очень даже не маленькую зарплату!
Возможно с какой-то точки зрения это правильный ход, всегда говорить работнику, что у него большая зарплата. Если работник будет думать, что здесь он получает больше - это ещё один плюс в сторону компании. Может этому их учат на курсах работодателей?
***
Но мы отвлеклись. Офис располагался в здании колледжа. Мы снимали часть крыла на первом этаже. Я был безумно рад, что наконец-то буду разработчиком игр. У меня в некоторых кабинетах в школе была кладовка - она располагалась за отдельной дверью в начале или конце класса. Вот в такой кладовке и разместилось 6 человек, 5 программистов (вместе со мной) и один из наших начальников. Сидели плотненько, спинами тёрлись друг о друга, особо на стульях не покатаешься.

Сохранилась только одна мутная фоточка, сделанная на старенький телефон. Но, что удивительно туда попала вся наша команда. Не помню, зачем я делал это фото. Может быть затем, чтобы через несколько лет добавить её вот в этот рассказ?
Андрей - наш лид. Остальные в нашей команде Дима, Таня, Сергей и я.

Андрея мы все уважали и доверяли ему. Хоть он и не всегда был приятен в общении, но спасал нас от нападок геймдизайнеров, художников и начальства. Да и вообще был хорошим программистом и человеком. И даже играл на барабанах.
Дима, был самым молодым из нас. Это один из самых креативных людей которых я видел. Созданные им домашние поделки (я про код разумеется) всегда были цепляющи и казались чем-то необычным, да и вообще были сделаны со вкусом. А названия переменных всегда будоражили воображение. Однажды он принёс мне килограммов 10 бананов, не помню какой был повод - может быть мой день рожденья.
Таня - обладала супер способностью писать код и смотреть фильмы одновременно. Так что иногда приходилось её пинать, чтобы быстро нажимала Alt-TAB, если вдруг приходило начальство. Слышал, что девушки и правда могут делать несколько дел одновременно. Ещё подкармливала нас сладостями и вообще прекрасно разбавляла нашу мужскую компанию.
Сергей - просто был хорошим программистом и мог трезво смотреть на вещи. Как-то сделал себе какой-то безумный хайр в панк стиле на голове - но ему шло.
Первым заданием было сделать чтобы на карте вместо одной одинаковой елки появлялись разные виды ёлок и лес выглядел разнообразнее. В прочем в этом не было ничего особенного и я довольно быстро справился.
Это было также первым место где я понял все прелести командной работы в гит, и узнал что такое тесты (однако не смог оценить всей их мощи, т.к. мы их не писали :)
Вообще это единственное место где была работа в команде. Где действительно была команда. Однажды нам дали задание не по нашему проекту, нужно было написать демку приложения за пару дней. И мы быстро распределили роли и задачи, и через пару дней всё уже было готово. К сожалению весь мой последующий опыт показал, какая это редкость когда люди работают сплочённо и с полуслова понимают друг друга.

***
За время работы там удалось сделать пару задач, которыми я действительно горжусь.
Одна из них это модифицированный поиск пути. Как обычно строится игровая сетка? Это сетка и каждой клеточке соответствует какое либо состояние. Под состоянием подразумевается занята она чем-то или нет. Персонаж также занимает клетку. Поиск пути, соответственно, ориентируется на состояние клетки.
Но дело в том, что геймдизайнерам неожиданно потребовалось чтобы персонажи могли ходить между объектами, но не могли проходить сквозь объекты (если объект занимает больше чем одну клетку).
На поиск решения ушёл день. А имплементация заняла полчаса. Собственно в этом то и радость, что модифицировать пришлось очень небольшое количество кода. Я лишь стал помечать клетки не просто тем заняты они или нет, а так-же id объекта которым они заняты. А при проверке смотреть не только клетку на которую идти, но и на соседнюю. В случае, если они имеют одинаковые id - проход запрещён. Разные - разрешён.
Ещё одной задачей был ипподром. Фактически это была игра в игре. Можно было построить объект ипподром, а потом заходить внутрь и делать ставки на лошадей. Боже, да это же почти казино! Это было законно? В общем сейчас уже не важно. Я попросил поработать в выходной день для этой задачи. Меня никто не отвлекал, так что я вошёл в раж и полностью написал всё за день.
Хотя когда наш совсем главный директор об этом узнал, то не был этому рад. Не знаю почему, но его возмутила работа кого-то в выходной день. Что ж, все к этому по разному относятся.

***

В прочем с директором я никогда не общался, за исключением одного случая, когда он на меня орал.
График у нас был строгий и опоздания не приветствовались. В какой-то момент, даже ввели форму в google docs, которую нужно было заполнить, если  ты опоздал более чем на час. Мою бунтарскую сущность на тот момент это сильно всколыхнуло и на следующий день я пригласил свою девушку на завтрак в 9:00 в кафе. Придя на работу ровно на час позже, описал в этой форме во всех красках, то как я сначала нежился в кровати, потом шёл по улице пригреваясь лучами солнца, а затем как прекрасно проводил время в кафе, вместо работы в маленькой, тесной кладовке с единственным окном заклеенным бумагой. Первое, что я услышал вечером от директора было не “Привет”, а “Я охуел!”. В общем, сошлись, на том, что это было просто шуткой (это в общем-то ей и было), но он видимо подумал, что-то другое.
Кстати через пару недель нас переселили в помещение побольше. До сих пор гадаю, связано ли это как-то.

***

Есть ещё одна вещь которой я не горжусь. Но после неё я дикий сторонник избегания человеческого фактора везде где это только можно.
У нас было админка (система где можно управлять пользователями, посмотреть всю их историю и в том числе безвозвратно удалить). Для удаления пользователя нужно ввести капчу, а именно посчитать сумму из двух цифр до 100 - обычно это останавливает от всяких случайностей. Как-то раз к нам пришёл баг который воспроизводился только у одного пользователя, и чтобы воспроизвести баг я скопировал базу себе на локальную машину и в локальной админке с ним работал. За один день баг пофиксить не удалось, так что отложилось на завтра.
Приползая с утра на работу со слипшимися глазами я решил, что нужно бы попробовать всё заново, почистить локального пользователя и скопировать его с продакшена. Легким движением руки я открываю админку, быстро считаю сумму и нажимаю delete. И дальше так не спеша доходит, что это админка была на продакшене.
Поговорили с директором, решили в итоге не тратить время и не восстанавливать пользователя. Вот так вот, решишь обратиться в службу поддержки с багом, а тебе всё обнулят.

***

В конце концов видимо игра перестала приносить доход и её прикрыли.

четверг, 16 февраля 2017 г.

Ретроспектива - часть 5, Уровень 2

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


I. Make coffee
Идея в голову пришла после реализации механики. Которая реализовывалась просто
из любопытства
Задача налить в банку сыпучие материалы в разных пропорциях. Траектории по которым сыпятся
ингредиенты рисуются игроком, все объекты неподвижны. Идейно нужно приготовить кофе, и чем
дальше, тем из большего количества ингредиентов состоит кофе и большее количество кружек
нужно наполнить.

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


II. Snowpark
Была идея создать очередную социальную ферму. Только вместо фермы у каждого был бы
свой снежный склон. Игрок должен был бы развивать “курорт” и привлекать посетителей.
Было написано довольно большое количество документации. Проработаны множественные аспекты
того как и что должно было работать.

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


III. London vs Aliens
Был найден просто гениальный художник. Если честно, не помню, как судьба меня с ним свела.
Но он жил и работал в Тайланде. Это один из проектов которые действительно жаль, что не удалось
довести до конца.

"Идея: Динамичный казуальный воздушный бой Описание: Ход игры будет представлять из себя короткие сражения легкой-средней степени сложности. В начале игры нам дается летательная бочка которую можно оснастить вооружением."
Дело даже дошло до демки. Однако мы очень много внимания уделяли деталям и будущим фичам.
Могли неделю обсуждать и думать над тем какой должен быть идеальный шлейф от двигателей корабля.
Простота - это важно. Как завещала GLADOS - Нужно лишь посмотреть на вещи объективно, увидеть, что больше не нужно, и удалить лишнее.
Постоянно хочется чего-то ещё добавить, и чтобы вот такая штучка была и вот такая - но это способно повергнуть проект в шторм из мелких деталей и в конце концов убить его.
После того как я подготавливаю видение продукта, всегда создаю после исходной версии - минимальную достаточную. И приступаю к реализации именно её. Это позволит выпустить продукт раньше (или даже просто выпустить). Все не критичные фичи убираются на второй план.



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

One more.
Если что-не получилось, это не значит, что вы чего-то не можете — это повод попробовать ещё раз. Звучит банально, но не все этого придерживаются. Даже если я 10 раз наступил на те же грабли и не смог себя заставить что-то делать, не значит что я не могу попробовать снова. Хотя как показывает практика, до 10 раз не доходило. Если что-то не получается несколько раз, то обычно я начинаю что либо менять в процессах и/или методах.

Ретроспектива - Часть 8







Впервые я попал в фирму далёкую от IT. Программистов нас было двое, мой “напарник” отвечал за сайт, а я сначала за клиентскую часть, а потом за весь технологический стек работы терминалов по продаже. Поскольку люди разрабатывающие до меня терминалы знали в основном PHP, то PHP был везде, и на клиентской и на серверной части и среди каких-либо скриптов выкладки. Если была вероятность решить задачу на PHP, она была решена на PHP.
***


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

В итоге случаи могли быть например такие:
- пользователь может купить 10 пакетиков с детским питанием в магазине А
- пользователь может купить 11 пакетиков в магазине А, но только через 2 дня
- и в принципе не может купить 12 пакектиков в этом магазине.
но например в магазине Б он может купить 11 пакетиков сегодня и 12 пакетиков через 2 дня.

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

Логика была сложной, и тут меня спасли тесты - было написано достаточно большое их количество на все возможные варианты товаров, магазинов и сроки доставки. Так что даже когда логисты хотели странного, и с первого взгляда нельзя было сказать, что требования противоречат друг другу или не полны - тесты сразу говорили своё резкое “НЕТ”, и разобравшись в причине падения можно было объяснять по каким причинам это сейчас сделать невозможно или спросить уточнения.


***


На момент моего прихода процесс паблишинга не был автоматизирован чуть больше чем полностью. И первое, что пришлось сделать это написать длиннющую инструкцию, чтобы не держать все шаги в голове.
Дальше мне удалось найти время и автоматизировать этот процесс (на тот момент питал любовь к ant - так что вся сборка и паблишинг были построены на нём). Получилось лучше чем обычно чем на картинке http://xkcd.ru/1319/. И все терминалы обновлялись по одному щелчку мыши.
Когда обновляешь порядка 50 машин по всему городу одним действием, начинаешь чувствовать могущественную силу в своей руке.Так что я купил большую красную кнопку с подключением по usb и повесил на неё обновление терминалов.
Теперь выгрузка обновлений происходила с должной церемонией открытия защитной крышки и уверенным нажатием на кнопку.
Big_Red_Button.jpg


***


Однажды к нам подошёл оператор колл центра и сказал, что пользователь жалуется на то что его имя само сменилось на Василий Иванович. Стали смотреть пользователя - и правда Василий Иванович, пол женский. При этом никаких записей о смене имени нет. Пока пытались разобраться в чём может быть дело пришла ещё одна такая заявка, потом ещё одна и ещё. Решив просто взглянуть на базу увидели, что все пользователи теперь Василии Ивановичи.
Нам сильно повезло, что тот кто стал виновником этого происшествия сделал это случайно(?) и ещё отзвонился нам об этом. Удалось быстро выяснить причину.
Дело в том, что пользователь с именем Василий Иванович решил сменить себе пароль на что-то вида “newpassword;”, сайт был написан на своих велосипедах и кто-то забыл экранирование поля пароля. Точка с запятой обрезала всю конструкцию WHERE в SQL запросе. В итоге часть полей в том числе имя и фамилия обновились у всех пользователей.
Вот они SQL инъекции в живую. Бэкап 6 часовой давности был в запасе. Так что отделались лёгким испугом.


Ретроспектива - часть 5, Уровень 1 - Dev Story: Catch The Moon

Сейчас появилось множество различных инструментов упрощающих процесс создания игры со всех сторон. (Программирования, графики, геймплея) Даже, целые конструкторы игр, позволяющие создать игру без технических навыков.
Написать игру уже может и 10 летний мальчик и 70 летняя бабушка.
В связи с этим родилось любопытство. А как быстро можно сейчас создать игру?
Насколько минимальными могут быть сроки разработки? Так же это был челлендж для себя самого.

Dev Story: Catch The Moon

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

Dev Story: Catch The Moon

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

Dev Story: Catch The Moon

Итого 8 часов ушло на программирование, и ещё 8 на графику.
Звуки были взяты из свободно-распространяемых.
Музыку заказывал отдельно. За небольшую цену мне написали отличный саундтрек, который сильно оживил игру.
Итого на создание игры ушло около 20 часов (Два выходных дня). Никаких бессонных ночей и бесконечного кофе. Только наслаждение прыгающим котиком.
К сожалению музыка была готова только через неделю и требовалось некоторое время чтобы выложить игру в AppStore и GooglePlay.
По этому игра вышла только через месяц после окончания разработки.
В итоге удалось создать не большую и интересную игру сократив время разработки до минимума.

Dev Story: Catch The Moon


Ретроспектива - Часть 3 - Первая работа

У всех бывают в жизни некоторые периоды неопределённости, когда перед тобой неизвестность и нужно выбрать куда двигаться дальше или когда понимаешь, что то чем ты по жизни занимаешься тебя не устраивает.
В один из таких периодов в преддверии окончания университета, в абсолютном непонимании чем же мне дальше заниматься, кем работать и вообще -  я решил что буду заканчивать учёбу и искать работу по специальности.
Решив подтянуть один предмет и стал ходить на лекции, которых не было у меня в расписании. В конце концов почему бы не воспользоваться этой чудесной возможностью бесплатно получать знания.
Через несколько занятий преподаватель заметил, что к нему ходит незнакомый студент. Подозвал к себе и после недолгого разговора, видимо убедившись в моих стремлениях, предложил мне работу.
Первое что нужно было сделать - это смоделировать в матлабе данные которые отдаёт радар гражданской авиации. Так я начал писать код не только для себя.
На вход подавалась исходная траектория самолёта, а далее зашумлялась в зависимости от точности радара. Сложности были в том что земля у нас ни разу не круглая, и в минимальном и достаточном для нас приближении имеет форму эллипсоида (Как будто сесть на мячик). А радар отдаёт дальность и углы под которыми относительно него летит самолёт. Так что чтобы получить адекватную математическую модель приходилось шаманить с системами координат.
Вообще всё это нужно для того чтобы повысить точность и надёжность отображения позиций самолётов в диспетчерской. Точно показать куда и где летит самолёт, а также не пугать диспетчера если данные о его положении вдруг не придут пару раз от радара.
Ближе к реальности всё оказалось несколько сложней, т.к. ошибки радаров не единственный “шум” который мы получали на вход нашей системы.
  • Радары бывают с разной частотой ответа (данные приходят в разное время)
  • Радары бывают с разной степенью точности
  • могут передавать высоту самолёта, а могут и нет
  • данные приходят с задержкой
  • сами радары находятся на разной высоте
  • некоторые особи радаров вообще не отдают угол места
  • и не забываем что всё дело происходит на эллипсоиде
В процессе работы гонять данные из одной системы координат в другую приходилось далеко не один раз.

Общий план был такой:
  1. Написать симулятор данных которые отдают радары
  2. Написать различные алгоритмы обработки данных
  3. Подать трек самолёта на вход симулятора радаров и получить зашумлённый ошибками трек
  4. Обработать разными алгоритмами зашумлённый трек и сравнить его с исходным
  5. Выбрать из написанных алгоритмов лучший
  6. ???
  7. PROFIT!!!

В первой итерации всё было написано в матлабе, работало страшно медленно. 300 секунд работы нескольких радаров могло эмулироваться несколько минут. Но результат был и какие-то выводы уже можно было сделать.
Далее необходимо было написать standalone симулятор, и чтобы работал быстро. Дети, что у нас работает быстро? Си плюс плюс! Ну это в умелых руках, и при наличии опыта, конечно.
Ну что плюсы так плюсы. Берём в руки книжку и вперёд. “C/C++ Программирование на языке высокого уровня” автор: Т.А. Павловская. Не скажу, что она представляет значительный интерес, но необходимые начальные знания она мне дала. В книжке был раздел про структуры данных и их теоретическую реализацию, но к сожалению раздел про STL упомянули недостаточно жирным шрифтом. Поэтому когда понадобился LinkedList был написан свой велосипед, сейчас уже смешно, но как первый раз осознал - было, конечно, стыдно.
Дальше нужно было переходить к делу. Нужен был UI. Дети, на чём пишут UI под windows? Правильно MFC(Microsoft Foundation Classes). Ныне, как я думал, мёртвый и забытый. Но на сайте последнее обновление датируется 2016 годом, так что кто-то что-то на нём ещё пишет.
Ну что ж берём следующую книжку “Программирование на Visual C++ 6.0 для профессионалов“ Круглински Д., Уингоу С., Шеферд Дж.. Читать её было настоящим кошмаром, т.к. одно из трёх слов на каждой следующей странице было не известным мне. Но сотней другой попыток и копирований примеров, отдалённо удалось понять как это должно работать.
Так, без системы контроля версий, каких либо соглашений о наименовании, архитектуры и прочих глупостей; по большей части велосипедами удалось написать рабочий симулятор треков самолётов.
Далее нужно было писать сам обработчик радиолокационной информации. Договорились о том что это будет отдельный модуль, без собственного UI только принимающий данные от радаров и передающий по TCP/IP дальше на отображение.
Жаждя повышения своих знаний о мире программирования на глаза попалась книга “Совершенный код” Стива Макконнелла. Она открыла на многое мне глаза, и стала некой основой того как должен выглядеть код. Сейчас понимаю, что я вообще не помню ничего конкретного из этой книжки, хотя думаю многим пользуюсь. Видимо настало время пробежаться по ней ещё раз. Свой экземпляр, ещё давно, я дал кому-то почитать, но к счастью коллега на работе поделился своим.

К этому времени мне нашли помощника.
Соответственно нужно как-то было организовывать общую разработку. Тут - то я и познакомился с SVN. Но уже тогда наши дела почему-то не заладились, и чуть позже перешёл на GIT. До сих пор не люблю и всячески избегаю SVN. Но сталкиваться приходилось не раз и каждый раз с ним всплывают какие-то неочевидные проблемы.
В пользу потенциальной кроссплатформенности и снижении затрат на продукт выбор был сделан в сторону Qt. Набравшись опыта при написании симулятора, понимая где можно не городить собственные велосипеды и уверенностью как должен выглядеть хороший код был разработан модуль обработки радиолокационной информации.

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

Ретроспектива - Часть 7

Совещание было назначено на на 11 вечера.
Свободный график - и люди радостно задерживаются допоздна, а потом же надо выспаться. В итоге привыкают и работают с обеда и до 3-х ночи, а случается и позже.
Работал я удалённо, но компания находилась в том же городе. Так что иногда мы виделись для того чтобы обсудить что и как делать дальше.
К этому моменту мы успели написать прототип и выпустить демо версию. Попадать внутрь нужно было в обход, т.к. обычный выход к тому моменту уже закрывали. В здании не было абсолютно никого. Где-то должны были быть охранники, но им видимо достаточно было наблюдать меня через камеру. Я поднялся на этаж, вошёл в пустое помещение офиса, дошёл до переговорной комнаты и открыл дверь.
Небольшое помещение с тёмно серыми стенами и ковролином, остеклённое с двух сторон, прозрачные стены завешены жалюзями. В конце помещения маркерная доска, а в центре стол человек на 10.
В переговорной сидит один человек - Даша - наш менеджер, смотрит в планшет, голову не поднимает. Я подхожу сажусь напротив некоторое время разглядываю её, но она не отрывает взгляда от айпада и кажется вообще не шевелится.
Я не спеша разглядываю комнату, или делаю вид, что разглядываю.
Должен подойти наш геймдизайнер - Андрей. Вообще он не то чтобы геймдизайнер на нашем проекте, но по каким-то причинам помогает Даше. Через некоторое время открывается дверь и входит Андрей. Здесь Даша наконец оживает и отрывает голову от планшета, и тут я замечаю, что её лицо всё в слезах. Приятная сладость ненависти и мести медленно накатывает на меня - Даша сидит и ревёт горькими слезами.
Как мы вообще докатились до этого? Разрабатывать игры это же весело и интересно!

За несколько месяцев до этого:
Даша смогла приехать только около 9 вечера, передала мне довольно тяжёлый полиэтиленовый пакет из под продуктов. Сказала, что никто не знает, что она их взяла, так что нужно будет обязательно в понедельник всё вернуть.
Я выложил из пакета на стол около 15 различных телефонов и планшетов.
Мне предстояло, дописать прототип до вменяемого вида, протестировать на всех девайсах, и выложить версию в публичный доступ.
Сейчас 9 вечера, а значит до релиза ещё есть около 12 часов. И кому нужен этот срочный билд, вряд ли случится что-то ужасное если отложить его на пару дней. Конечно, получив такое предложение в третий раз - я уже отказался. Но в этот первый раз я был полон сил, в конце концов это же очень крутой челлендж.
...
За окном было всё ещё  темно, летом в это время уже светает. Кажется готово. Неожиданно приходит осознание того, что я голоден. Даша не отвечает видимо легла спать - ей завтра с утра представлять, то что я сейчас тут сделаю. Нужно сходить в магазин и купить какой-нибудь еды. Остались последние приготовления и можно идти.
Опа, у нас нет иконки для приложения. Почему об этом никто не подумал? Быстро накидываю блик на самый симпатичный игровой объект и делаю ресайз до нужных размеров. Готово. Хотя нет, это было не так быстро к 24 часу работы концентрироваться становится достаточно тяжело, и даже для простой задачи приходится прилагать очень много усилий, чтобы не потерять фокус.
Upload. Publish. Done.
Зато теперь я могу говорить, что писал код 24 часа без перерыва.



Думаю, это самая неприятная часть. Довольно долго думал, над тем что же тут такого интересного описать. Но особо ничего не нашёл, в общем-то почти ничего интересного и не было.
У меня был огромный список того с чем пришлось столкнуться на этом проекте. Не хороший список. В общем-то это довольно большой список из того как не должны работать другие. И пунктов 20 из них это то что стоит исправить лично Даше в её работе и поведении. Хорошо, что я так и не показал ей его.
Есть и другой список, сильно меньше. Несколько пунктов, того что я вынес из этого проекта:
  • Не работать 24 часа в сутки
  • Не использовать не прошедшие боевые испытания технологии в условиях сжатых сроков
  • Не пускать, даже не зависящие от тебя напрямую вещи на самотёк