Лига программистов

Добрый вечер. Не буду томить и сразу начну.

Половину своей жизни мечтаю о своей игре,  а именно, собственной Guitar Hero, с блэкджеком и песнями. Простую, браузерную, в которую можно играть как на телефоне, так и на ПК.

В бородатые времена, было что-то подобное, называлось Flash Guitar Hero. Написанная на флэше, в которую можно было играть на сайте, либо скачать себе на ПК и играть без интернета.

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

И я не программист, кстати.

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

Есть midi-файл, распарсив его, я получаю очень много информации:

Сами ноты:

[

{

"durationTicks": 1, //длинна ноты

"midi": 96,  //струна, на которой находится нота

"time": 2.016804  //секунда, на которой звучит нота

}, {

"durationTicks": 1,

"midi": 97,

"time": 2.016804

},

]

BPM:

[{

"bpm": 119, //bpm, собственно

"ticks": 0  //тик (он потом конвертируется в секунду), на которой меняется bpm

},

{

"bpm": 99,

"ticks": 768

},

]

Ну а дальше, дело за малым, я решил выбрать JQuery,  так как немного понимаю его.

var notesJSON = "notes.json";

var bpmJSON = "bpm.json";

$.getJSON(notesJSON, {format: "json"}).done(function(data) {

$.each(data, function(index,value) {

var TimeToPX = value['time']*762+50; //конвертирую секунды в пиксели

var height = parseInt(value['durationTicks'])+parseInt(109);

$('.notes').append('<div class="note"></div>');

var notesHeight = $('.notes .note:last-child').attr('data-px');

$('.notes').css({'height': parseInt(notesHeight) + parseInt(50)+'px'});

});

});

Поясняю:

var TimeToPX //конвертирую секунды в пиксели (шизик, да)

var height  //делаю высоту у нот

$.getJSON(bpmJSON, {format: "json"}).done(function(data) {

$.each(data, function(index,value) {

var ppq = 192;

var bpm = value['bpm'];

var bpmppq = bpm * ppq / 60;

var ticks = value['ticks'];

var speed = (289400 / bpm) *100;

var bpmtime = ticks / bpmppq;

song.addEventListener('timeupdate', function () {

var songStart = parseFloat(song.currentTime);

if (songStart > bpmtime) {

var notesHeight = $('.notes .note:last-child').attr('data-px');

var translate = parseInt(notesHeight) + parseInt(50);

$('.notes').animate({bottom: '-'+translate+'px'}, speed, 'linear');

}

}, false);

});

});

Тут все понятно. Все переменные для той самой конвертации тиков в секунды.

Переменная speed "прокручивает" блок с нотами в низ с той скоростью, которую мы распарсили из bpm.json. И которая меняется когда надо.

Так а что в итоге? А то, что, как я понимаю, JQuery не подходит для этого, на андроиде жутко все тормозит, как будто я запустил ПК-ашный Киберпанк на Редми 6. Но вот на Айосе тянет все отлично.

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

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

А можем вообще вместе ее доделать.

Живой пример того, что я сделал - http://z33376pn.beget.tech/gh/ - играть можно только на телефоне. Нажав на play в левом верхнем углу. Но посмотреть, как движутся ноты, можно на любом устройстве.

Пример другой игры на JS без тормозов:

https://github.com/jyschwrtz/JS-Hero

А вот пример того, что хочется получить в идеале:

https://github.com/henryzt/Rhythm-Plus-Music-Game

Intro

Периодически на ресурсе можно встретить авторские истории в стиле: “Как я стал разработчиком на Х в 30 лет” или “Как я перешел в IT на позицию Y в 40 лет” и т.д.

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

Работая в IT (software development) больше 25 лет в разных компаниях (западные, до 10к. человек) на менеджерских позициях, я наблюдал кого компании ищут, как происходит отбор, как кандидаты себя ведут на интервью и как они меняются попадая в команду, кто в итоге остается, а кто нет.

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

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

Scope Definition

Для кого это?

Зачем люди вообще идут в IT? Цели у каждого, конечно же, могут быть разные.

И логично, что от цели и причин будут зависеть и весь остальной выбор и следующие шаги.

Но я бы хотел сфокусироваться на 2-х самых популярных и прагматичных целях, которые можно встретить:

1. Возможность работать удаленно (актуально для тех, у кого в месте их проживании не очень хорошо с доступной работой offline. Актуальность особенно выросла в период локдауна во время ковида);

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

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

С чего начать?

Общий большой план может выглядеть примерно так:

1. Выбираем позицию(роль) на которую хотим пойти;

2. Изучаем минимально необходимый объем материала (+получаем первый тестовый опыт);

3. Выбираем компанию;

4. Проходим собеседования;

5. Пытаемся удержаться;

6. …

7. Profit?

(Пункты 1-3 могут быть в разной последовательности, т.к. все действительно зависит от стартовых условий.)

Задайте себе простые вопросы:

1. Я уже знаю кем точно хочу быть и чем заниматься?

2. Или может я уже что-то умею и/или хочу на чем-то специализироваться?

3. Или может есть компания, в которую я хотел бы попасть и не важно кем?

(если уже что-то известно, то от этого и проще отталкиваться)

Важно:

Эмпирически, минимально-реальное время на первоначальное обучение - это месяцев 3-6.

И с вами уже могут начать разговаривать на собеседованиях.

Но это если ориентироваться на full-time (полный рабочий день) на обучение. Если планируете оставаться на текущей работе и учиться параллельно, то на обучение может потребоваться год или два.

Но как обычно, нюансы в деталях.

Поэтому чуть подробнее по пунктам.

Кем быть? (О ролях)

“-Кем ты хочешь быть в IT?

-Не знаю, а кем можно?”

(реальный диалог)

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

Когда говорят об IT, то самые популярные позиции которые на слуху - это “программисты” и “тестировщики” (которых еще ошибочно называют QA)

Но конечно же, мир IT гораздо шире.

В целом IT сейчас это больше про “информацию” и ее обработку, чем про технологии как таковые.

Процесс разработки. Как это происходит и кто участвует?

Софтверные компании крутятся вокруг информационных систем (неких программных продуктов, своих или заказных, не важно) и на всем жизненном пути системы, для ее поддержки требуются разные роли.

Процесс разработки (инициализация)

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

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

Процесс разработки (реализация)

Дальше идет собственно сам этап разработки.

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

В целом, общий процесс разработки выглядит примерно так:

- бизнес аналитики работают с заказчиками/пользователями, собирают первоначальные требования и обосновывают экономические выгоды (часто это роль на стороне заказчика и вы можете ее занять в ИТ департаменте своей текущей организации, например, медицинского или государственного учереждения),

- системные аналитики превращают требования в описания проектировок,

- UI/UX дизайнеры рисуют пользовательские интерфейсы,

- архитекторы, на основе общих проектировок, создают технические описания реализации, (архитектуры) и реализуют базовые вещи: основные интерфейсы/компоненты/фреймворк/базу данных и т.д.,

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

- тестировщики проверяют соответствие реализации требованиям,

- документировщики оформляют пользовательскую документацию, системные сообщения и переводы,

- всевозможные администраторы/конфигураторы (их еще не совсем корректно называют devops) обеспечивают всю физическую инфраструктуру и развертывание системы в работу и делают систему доступной для пользователей (сервера, сети, доступ, и т.д.)

Процесс разработки (поддержка)

Когда система уже готова и запущена в продукции, дополнительно появляются роль

- Специалиста поддержки (1st line support, 2nd line support) - которые обрабатывают заявки от пользователей (проблемы, вопросы, улучшения) и помогают/направляют на разработку

Процесс разработки (дополнительные роли)

Еще добавьте

- всевозможных узких специалистов/консультантов которые нужны только в конкретном проекте (блокчейн, GDPR, искусственный интеллект, BigData, эксперты предметных областей и т.п.),

- возможных social специалистов, вроде Mental Health specialist (что-то среднее между психологом и коучем который следит чтобы в проекте никто не перегорел - обычно он один на организацию)

Оберните сверху всевозможными

- менеджерами процессов,

- дополнительными службами управления качества и

- безопасностью,

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

Так что же выбрать?

Вот во всем этом вы где себя видите???

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

- “Не знаю, но вот точно не <название_роли>, потому, что <причина>!”

- “Не знаю, но вот это, <название_роли>, кажется интересным и я бы попробовал”

- “Просто не знаю”. (А что проще? Или что я смогу научиться делать?)

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

В идеальном варианте, нормальное распределение: 1 человек = 1 роль.

Но довольно часто бывает, что в конкретном случае (проекте/компании) выделенная роль не требуется вовсе или требуется в ограниченном виде (или компания просто пытается сэкономить).

Тогда роли начинают объединять.

И может получиться что человек например “программист”, но он в себе сочетает роли программиста, аналитика и UI дизайнера.

И это одна из причин почему можно услышать мнение что “в IT надо очень много знать и уметь делать кучу разнообразных вещей”

Если сразу нет каких-то предпочтений и хочется выбрать с позиции “минимального времени на обучение”, то по наблюдениям самый низкий порог эффективного вхождения (из популярных ролей), это роли:

1. Поддержка пользователей (1st/2nd line Support specialist)

2. Тестировщик

3. Программист

Что изучать? (О скилах)

Условно все навыки можно на hard skills (технические) и soft skill (не технические).

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

Хотя это как раз и не важно. Вернее не настолько важно, как может думаться.

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

В компаниях это тоже понимают, поэтому если ищут джуниора, то уровень hard skills, как правило, должен быть “минимально достаточным", чтобы просто пригласили на собеседование, а там уже будут проверять немного другие вещи.

Что касается развития hard skills как таковых, то для всех кто не "программист / администратор” процесс первоначального обучения достаточно straightforward (прямолинейный):

для аналитиков есть их BABOK, для 1-st line суппорта - ITIL, для тестировщиков - ISTQB, для QA и прочего качества - CMMI, ISO, IEEE, для менеджеров PMI/Agile, и т.д.)

А вот для программистов и администраторов все гораздо сложнее и не тривиально.

Потому что это уже ТЕХНОЛОГИИ!

(Т.к. в комментариях встречал много сообщений про интерес именно к программированию, то расскажу о своих наблюдениях именно о технологиях в программировании).

Технологии (как выбрать?)

Технологии. Их много, они разные и везде требуются разные наборы (technology stack). Знать все не получится физически и для специализации приходится выбирать что-то одно (иначе в долгосрочной перспективе будет проседание по зарплате), а еще они имеют свойство быстро устаревать и каждый год, как грибы, вырастают новые.

Конечно, если хочется быть на переднем крае (on the bleeding edge), или в модерновом стартапе, то да, важно следить за трендами и вовремя переключаться.

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

А вот в конкретных компаниях/проектах все может быть совсем не так.

Т.к. при переходе в IT потом придется где-то работать, то эффективным может быть для начала посмотреть, какие сейчас есть актуальные вакансии и что там перечислено? (совпадающие названия и будут теми технологиями которые сейчас “популярны / востребованы”)

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

Технологии (как начать изучение)

Ок, допустим смогли определить с какой технологии попробовать,

что дальше, с какой книги/курса начинать изучение, так, чтобы это было эффективно?

И тут нет “серебряной пули” (идеального решения). Т.е. для начала можно пробовать любую доступную книгу/курс/ресурс для новичков (где есть слова for dummies, за 24 часа, 30 дней, или любую другую - для начала это не принципиально).

Важные критерии на этом этапе:

1. Понимать, что там написано (т.е. чтобы сам язык был доступным для понимания)

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

На этом этапе первичная цель - просто начать что-то изучать, попробовать что-то сделать и оценить ощущения:

1. Было ли легко разобраться? Или наоборот приходилось продираться?

2. Было ли интересно разбираться? Или безразлично?

Потом, для сравнения, попробовать другую технологию и сравнить ощущения.

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

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

И если работа вас “не прет”, то продолжать конечно же можно, просто может быть чуть сложнее.

Технологии (продолжение обучения)

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

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

Хотя конечно эта грань “я уже умею достаточно хорошо программировать, чтобы работать или еще нет?” во многом субъективна и условна.

Есть и вполне объективные критерии именно на знания (не навыки), которые одинаково могут признаваться и коллегами и компаниями.

Это официальные сертификации. А курсы для подготовки так же можно рассматривать как вариант обучения.

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

Это как некое внешне авторитетное подтверждение, что знания в конкретной предметной области / технологии более-менее выровнены.

(продолжение следует)