Юрий

Создание ИТ бизнеса в современных условиях: возможно ли?
конечно.

стартапов сейчас миллион, пусть выстреливает 1% - но ведь шансы всегда есть. Да и вообще - даже если не выстрелит - получите опыт, и у следующего проекта шансов будет больше.

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

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

Тоже пару лет назад изучал webgl, тоже было интересно (пригодилось один раз по мелочи, но не жалею ).

Поговаривают что WGL бесполезно изучать по исходникам других приложений и в этом есть доля правды. Хотя исходники пригодятся позже когда будете понимать основы.
learningwebgl мне в свое время помог, я выбрал путь изучать именно без библиотек - очень полезный опыт потом можно перенести и на десктопный openGL, хотя версии там более новые.

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

далее разобраться с матрицей трансформации - векторной арифметикой - посмотреть какие функции для векторов и матриц есть в шейдерном языке.
разобраться для чего нужны пикселные и вертексные шейдеры. Лично мне в этом плане очень сильно помогло чтение спецификации OpenGL ES 2.0 (гуглите в сети).

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

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

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

Надеюсь помог и желаю удачи!

если есть несколько вещей более значительных то не нужно, если нет - то пишите.

Инфы море на одном только хабре habrahabr.ru/search/?q=%5B%D0%B1%D0%BE%D1%82%5D&ta...

от себя добавлю что основные методы это
1) простейший понятный способ - поиск нужного элемента на экране и кликание по экрану, или клик по указанным координатам. я в основном использую этот способ, так как вмешательство в игру минимальное - ее не надо ломать, для онлайн игр - меньше шансов получить бан. Подходит для простых игр, в основном те что 2D пошаговые.
Гуглить отправку событий мыши и клавиатуры на выбранном вами ЯП (java robots например).
Минусы - игра должна быть постоянно открыта на экране и иметь фокус (можно решить - запустив игру с ботом в виртуалке).

2) для онлайн игр - изучение протокола обмена данными с сервером. нужно изучать куда отправляются/откуда получаются данные и в каком формате. пишем программу которая эмулирует клиент игры. очень хороший способ - для очень интерактивных игр - максимальная скорость. Способ довольно сложный надо реверсить протокол (гуглить wireshark) и возможно само приложение (гуглить дизассемблирование / декомпиляция). Если игра браузерная - то все может быть проще - запросы и ответы можно смотреть в консоли браузера. Очень перспективный способ - визуальный клиент не обязателен - можно делать армию ботов и размещать на серверах - скорее всего они будут потреблять немного памяти и процессора и возможности впечатляющие.

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

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

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

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

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

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

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

для получения токена пароль передается только один раз, его конечно тоже могут перехватить, но шансы меньше + для запроса авторизации можно использовать https

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

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

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

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

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

Падает ли скорость от ORM?

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

Падает ли скорость от ORM?

нет. скорость разработки может сильно возрасти, если уметь с ней работать.

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

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

хорошая орм не связывает руки а имеет возможности для тонкой работы на более низком уровне.

я использую пару лет doctrine2 для php, хотя до этого много лет писал запросы руками. возвращаться не хочу, хотя и могу.