Alexander Pikeev, зачем? В садике научат писать и читать, а дальше по учебникам. Учителя не лучше тех кто курсы делает. Они вообще из прошлого века и ограничены гос программой, которая как и все с префиксом гос - фигня.
Вообще в таких случаях в корне проекта создают global.scss и уже в него импортируют все необходимое. Если вы подключите его в webpack, то ide все равно будет ругаться, так как не будет понимать откуда переменные берутся. Разве нет?
Роман Якимчук, если архитектор подготавливает спецификацию с uml + bpmn2 + описание, и при этом происходят описанные вами казусы, то либо у вас в командах джуны , что не допустимо по agile, тем более если они на удаленке. Либо они просто не понимаю диаграм и поэтому додумывают сами. Первый случай не исправить. Во втором необходимо процесс обучения налаживать. Еще может быть что архитектор через чур накручивает.. Но это реально нужно знать хотя бы стек. Есть стеки в которые разработчики пришли от архитектурной усталости и поэтому архитектор из классики может их просто бесить. Здесь необходимо по ситуации решать, вести диалог. Может команда переубедит архитектора, а может наоборот. Если в командах люди не могут договорится, то это не команда, а не небольшая толпа. Виноват в этом лид.
Роман Якимчук, других вариантов нет. Искать одного ответственного за ревью бесмысленно. Представьте форум, на котором раз в день приходит чувак с рулончиком кода и просит посмотреть что в нем не так. Уже дорож пробирает.. А у вас таких 100. Кто подобное вытерпит? Только все сразу. Если нет денег на крутых разработчиков, то только так.
Роман Якимчук, жесткое соблюдение конвенций + линтенры, которые просто не позволят написать неправильный, с точки зрения употребления конструкций, код. В ревью должны участвовать все, поскольку это ещё и процес обучения. Его можно и попарно выполнять. Доверие, должно быть доверие. Если нагружать лидов мелочами, они убегут от вас. Вторая линия защиты - тестирование.
Про несоблюдение архитектуры не понятно. Я не понимаю как можно выйти за пределы архитектуры ограниченной спецификацией. Если всего этого нет, то термин архитектор, как такого, и звучать не должен. Просто чувак, который понимает, вроде бы как больше остальных. И да, agile предполагает самостоятельные единицы. От команд состоящих из джунов даже благословение папы римского не спасет.
У меня такое представление о разработке было в первые года обучения. На самом деле все намного проеще, но откроется это лишь с опытом или обучением, коего сейчас навалом. Читайте все что связанно с agile, чем больше, тем лучше. И помните, доверие и делегирование - залог здорового руководителя.
UPD: Другой ответ вы если и получите, то он будет безумен, поскольку незная какой проект, на каком стеке он разрабатывает, какие критерии к нему предъявляются, какой уровень компании (её финансовые возможности) - ответ дать нельзя. Кроме того, нужно знать ваш уровень чтобы понять о чем конкретно вы спрашиваете.
egorkozelskij, я никогда не пользовался Realm, поэтому сказать не могу. Кроме того, я слышал, что существуют удаленные стейт-манагеры созданные на redux. То есть, обычный redux предполагает синхронизацию данных между разными компонентами на клиенте, а та библиотека рассматривает клиенты, как компоненты.
Если писать подобное самому, то использовать сокеты. Синхронизация должна быть завязана на времени. id генерирует только сервер. При создании объекта в оффлайне нужно обертывать его в объект имеющий собственный уникальный идентификатор и говорящий что он временный. Тогда сервер добавит записи в БД и вернет с его помощью id и время обратно. а там синхронизировать. Как-то так. Все зависит от предполагаемой частоты обновления с разных устройст. Если предполагается очень часто, то вообще всю логику нужно на сервере держать.
Иван Шумов, ленивая загрузка + изображения как у medium, которые подгружаются постепенно, требуют как раз base64 + не понял про один поток.
UPD: понял про поток. Спорный момент. Загрузить файл целиком или загрузить меньший файл, а затем сто запросов сделать к серверу. Единственный момент, такие картинки не кешируютися. Это единственное что может вызвать замедления.
Просто на заметку, все вами перечисленное, никакого отношения к mobx не имеет. mobx это всего-лишь навсего слой для работы с данными. Ему безразлично как вы их получите и преобразуете их.
Magneto903, сложно сказать в чем проблема не разобравшись в коде. также не зная ваших способностей мне сложно давать советы. Создание игр это не просто. Можно легко написать сайт, приложение или сервер ни разу не прибегнув к оптимизации. Но игры требуют глубокого познания в специальных игровых архитектурах заточенных под оптимизацию. Ни один крутой движок не позволит работать с фильтрами вот так просто. В специальных программах создают эффекты, которые затем с помощью шейдеров совмещают с динамической анимацией. При этом стараются большую часть ддинамики реализоавать статической. При чем как сразу, так и в коде.
Magneto903, честно сказать я не уверен на все сто, но мне кажется, что у pixi фильтры с поомщью шейдеров сделаны. Вообще да, фильтры расчитываются на cpu, так как они почти всегда векторные. Но поскольку pixi это растровый движок рендера, то есть он не имеет ничего векторного, то скорее всего и фильтры у него за счет шейдеров реализуются. Вот только вы напишите один большой шейдер включающий и блур и опасити и смещение, а у них для этого будет несколько шейдеров. Хотя по хорошему, они все должны в один группероваться, но это уже тонкости, которые мне не известны. Я избегаю подобных ситуаций. Игры делать нужно так чтобы получать удовольствия, а не создавать монстров, от которых голова будет болеть, как-будто палкой ударили.
Magneto903, во первых крутой графон, это всегда компромисы. Вы думаете крутые игры делаются вот таким образом который вы описали? Глаз игрока не сможет заметить разницы между реалтам эффектами и пререндером + маски. А то скорее всего второй вариант покажется более атмосферным. Во вторых можно попробовать шейдеры, которые все будут в одном делать. Фильтры, по факту это тоже шейдеры, но менее оптимизированные. Вариантов очень много и выбор зависит от конечной картинки у вас в голове.
Или вот можно сделать два вида - обычная скорость и ускорение при взрыве. Компенсировать масками и\или прозрачностью. Поскольку геометрия астеройддов динамическая, то картинки не нужны, нужно свою систему пререндера писать. И все это рендерить в один канвас.
kk95, крутой программист постоянно хочет и можут писать любые приложения. Десктоп, мобильные, игры, сервера - он не видет разницы. Для него это все игрушки, в каждю из которых хочется поиграть.
Да, уроды есть везде, но это зависит от характера. Я не встречал уродов которые были бы не достойны своихх мест. То что они говна кусок не делает их хуже слюнтяев.
Зря что при рассуждении использую свой немалый опыт? А как мне тогда вообще жить? Положится на чужой или просверлить себе лобную долю дррелью чтоюы вообще не думать?
Vilmof20, если вы умеете рисовать, то почему бы и нет! Иначе также картина. Без особых навыков вы будите никому не нужны. Всем нужны крутые моделисты. Вы бы стали играть в игру со стремным артом? Нет! Мало кто играет. Поэтому компаниям нужны как миниму опытные модельеры, которые будут не наугад вершины в пространстве тыкать, и создавать продуманные в голове модели за считанные минуты. Посмотрите моделинг на скорость. Вот так нужно уметь. Иначе вы как и программист стажер, деньги зарабатывать не сможете. И да, мы в россии, у нас хотят поиметь всех по полной. Поэтому если вы талантливый модельер, то вы все же уступите тем, кто умеет текстурить, создавать концепты и прототипы. Простыми словами, выгоднее универсалы, которых сейчас уже много. Новички нужны только талантливые.
Когда-то нельзя было устроится на престижную работу, если у тебя не было блата. Сейчас нельзя устроится в it, если у тебя нет родственника ментора. То есть с нуля можно войти только если ты гений или тебя ментор натаскал.