Тут скорее не про сессии, а про множество игр. Каждая игра - новые механики, в которых разбираешься. Так что да, так проще разбираться в механике, если с подобной системой уже сталкивался, или изучил множество других.
Вполне можно многие алгоритмы отработать и построение систем. Получить базовое понимание сложности процессов, конструкций(иначе получить весьма сложно и совсем не дёшево). Расширяемость систем, их изменение. Завод в факторио живёт так же как и программа.
Конвеер - это всё же неразделимая часть в игре, из которой уже что-то делается.
2 - это из вредных советов прям. Когда в математике пропали цифры, я её понимал, но то как это преподавали - это идиотизм
1 пункт так же весьма так же из вредных. Находить полезно. А вот использовать взаимосвязи между неочевидными абстрактными понятиями... в энтерпрайзе, мягко говоря, за это надо отлучать от клавиатуры
Игры разные. Для ФПС 200+ скорее проф. уровень сейчас. Игровые стандарты всё ещё около 75. Для некоторых нужно много оперативки, хороший проц, вполне обычный монитор. Для других важнее видео и его объём. Но просто для игр сейчас почти всегда достаточно довольно слабого компа.
Это как? По принципу, там он плох/не умеет, так что он не для этого?
А вообще, для работы это дорогая фиговина, которая ещё и может меньше, чем ПК на интел, и поддерживает меньше программ/меньший функционал! По работе не редко слышу про тормоза и вылеты, что оказывается из-за нехватки оперативки(графика, объём растёт с экраном) потому как: a) большое кол-во взять сразу дорого б) через несколько лет этого уже мало И проблемы с рабочими программами, потому как та же поддержка М1 идёт со скрипом. Вот даже программа уже недавно заработала. Но плагин к ней нет) По неразрешимым проблемам в работе они на первом месте среди всех систем. В разборе проблемы не редко сказывается итог "ну и не надо". Хотя самих проблем меньше, либо они часто стандартные.
"Понять каким образом нужно строить канал рекламы" - для меня это норма работы, не связанная с обучением. Всегда что-то надо понимать - обычная работа, где схема по указанному вопросу проще схемы загрузки небольшого приложения во много раз.
А обучение - это про другое. Всё это математика, принципиально новые подходы, просто большой объём алгоритмической информации. И всё это завязано в языках, фреймворках, схемах, статьях, безотносительно текущей работы. Когда это понадобится? Может даже и никогда, а может ещё вчера.
Это безотносительно рынка. Одна и та же задача одного качества стоит по разному на разных стеках. Для типовых задач по российскому правовому полю 1С отлично подходит. Но иногда, когда нужно сделать что-то сверх базы, то ценник резко растёт в космос. И не из-за того, что задача имеет сложную программу, ведь так споткнуться можно даже на банальном.
О качестве архитектуры говорит уже выбор типизации. Изначально язык рассчитывался как лёгкий скриптовый, для небольших задач. Но постепенно задачи росли, а язык тот же в основе. Как и многие прочие аспекты платформы.
Это переводится так: Когда потребуется работа не из "коробки", то это будет стоить х10 от обычной стоимости. А по такой стоимости это либо критично важно и делаем, либо и не нужно вообще, жрите что дали)
Наличие методов в компонентах — всё тот же ООП, но не ECS. Последний тут(в примере верной реализации автора) вообще никаким боком.
Один из вариантов — обычный подход Unity3D(в посте очень похожий подход, создаётся впечатление, что именно оттуда и содран) с контейнерами в компонентах. Некоторые данные, которые требуют большого количества операций в кадр в компонентах заносились в списки и обрабатывались отдельно для каждого списка(вот это похоже на ECS). И по мне так это много лучше, чем переделывать весь проект под DO, т.к. у ECS тоже есть проблемы, в т.ч. с производительностью.
Одна из проблем ECS — много независимого различного кода, выполняемого за цикл небольшое количество раз. Да, делать перемещение и отрисовку с 10к объектами и парой методов ECS даёт огромный прирост производительности, а вот с 10к методами работать это будет как тот же Update. Другая проблема — писать код для разовых действий. Интерфейсы на ECS? Конечно можно, но зачем? Получается множество контейнеров данных(объектов, компонентов), где рабочий набор всегда один. А это ни чуть не лучше ситуации с Update по производительности, а по сложности написания кода много сложнее.
Только пока это короткая ситуация. При условиях уже высокой информатизации выгоднее один программист-бухгалтер, чем 10 бухгалтеров. Вся экономика перестаёт развиваться и работает больше не на новое, а на поддержку старого, с минимумом изменений и риска. В таком случае часто ИТ-шники на поддержке всё так же очень нужны, нужнее любого балласта(в этих условиях) из маркетологов, продактов и т.д. Но не нужны любые стартапы, игры, развлечения в целом.
Несколько ошибок. Надо считать все условия, собирая комбо - вышка, ИТ, акредитация, обеспечение инфраструктуры, внедрение/разработка. Чтобы норма работала нужен не ТГ, а акт, закон и прочее(да ещё не всякий).
На сколько смог выяснить, для получения отсрочки! организации нужно подавать списки. В списках нет, забыли подать, попутали и всё равно позвали? Ну когда-нить разберутся, а пока они заняты, вали куда сказали.
У вас не совсем корректные представления о цене жизни в Мск и СпБ. 300к это ниочём. Для хорошей квартиры не в центре, а в середине города, нужно 50+ млн. Такое легко могут себе позволить только некоторые бизнесмены, ну и чиновники.
Чтобы стать подходящим под категорию A необходимо немного опыта. А после получения этого опыта, A от B отличается только непосредственным руководством, ну и доступом ко всей необходимой инфе)
Премия отдельным приказом - право. Премия записанная в ТД - обязанность. Даже чтобы после правильного составления положения, лишить премии, должны быть проведены соответствующие действия, которые явно покажут причины, которые приведут к потере премии. Постфактум лишить премии не получится. Так же нельзя будет лишить возможности её получения просто отгородив работника от работы.
Вообще, можно добиться лишения премии, только вот не дешевле ли будет заплатить по итогу?
В принципе можно. Писать тесты отправить, к примеру. Но если смотреть именно о задачах программирования, то это всегда новая задача, не похожая при первом приближении на прошлые. Это сами по себе задачи которые не поддаются простой автоматизации, т.к. если поддаются, то эта автоматизация и есть задача.
Не для стажёров, настолько, что если это может сделать стажёр - значит это можно автоматизировать и заменить другим спецом(тестером, админом, манагером, техподдержкой и прочими).
С джунами получше, но они крайне неудобны. Там где мидлу надо поставить задачу в 10 слов, для джуна надо писать абзац или страницу, в которых он ещё и запутается, либо поддерживать и проверять по ходу, а лучше всё вместе. Получается, что задачу именно по разработке в нужном качестве джун не выполнит сам в большинстве случаев. Т.е. можно дать только те задачи, которые вполне автоматизируются, но на которые нет времени, или жалко его тратить. Ну или по принципу применения - дать обособленную вещь, которую в случае проблем проще переписать, чем править и следить в большей части за рамками работы. Но так не достичь высокой эффективности.
В соседней ветке был пример с DTO - это вообще мелочь по времени, больше возьни с объяснением что и для чего это и как этим правильно пользоваться, да и зачем. Для мидла это минуты, а для джуна - часы. Хотя тут и можно применить, только вот и это автоматизируется аж несколькими способами. А когда натаскаешь он будет уже мидлом)
И ещё одна вещь - с сеньорами можно обсуждать программу свободно, не касаясь языка программирования вообще.
Алгоритмы тоже не являются программами, примерно как наваленная груда кирпича ещё не здание) Оказалось, самое сложное - доносить о том, что надо писать программы, а не код или алгоритмы. И исходить надо при проектировании из программы, используя алгоритмы и код лишь как инструменты. Не редко выходит иначе даже после 5 лет работы программистом.
Тут скорее не про сессии, а про множество игр. Каждая игра - новые механики, в которых разбираешься. Так что да, так проще разбираться в механике, если с подобной системой уже сталкивался, или изучил множество других.
Вполне можно многие алгоритмы отработать и построение систем. Получить базовое понимание сложности процессов, конструкций(иначе получить весьма сложно и совсем не дёшево). Расширяемость систем, их изменение. Завод в факторио живёт так же как и программа.
Конвеер - это всё же неразделимая часть в игре, из которой уже что-то делается.
2 - это из вредных советов прям. Когда в математике пропали цифры, я её понимал, но то как это преподавали - это идиотизм
1 пункт так же весьма так же из вредных. Находить полезно. А вот использовать взаимосвязи между неочевидными абстрактными понятиями... в энтерпрайзе, мягко говоря, за это надо отлучать от клавиатуры
Не раз бывало про паттерны, людям, не занимающимся программированием. В принципе, если само слово паттерн человек понимает, то объяснить можно.
Игры разные. Для ФПС 200+ скорее проф. уровень сейчас. Игровые стандарты всё ещё около 75. Для некоторых нужно много оперативки, хороший проц, вполне обычный монитор. Для других важнее видео и его объём.
Но просто для игр сейчас почти всегда достаточно довольно слабого компа.
Это как? По принципу, там он плох/не умеет, так что он не для этого?
А вообще, для работы это дорогая фиговина, которая ещё и может меньше, чем ПК на интел, и поддерживает меньше программ/меньший функционал! По работе не редко слышу про тормоза и вылеты, что оказывается из-за нехватки оперативки(графика, объём растёт с экраном) потому как:
a) большое кол-во взять сразу дорого
б) через несколько лет этого уже мало
И проблемы с рабочими программами, потому как та же поддержка М1 идёт со скрипом. Вот даже программа уже недавно заработала. Но плагин к ней нет)
По неразрешимым проблемам в работе они на первом месте среди всех систем. В разборе проблемы не редко сказывается итог "ну и не надо". Хотя самих проблем меньше, либо они часто стандартные.
"Понять каким образом нужно строить канал рекламы" - для меня это норма работы, не связанная с обучением. Всегда что-то надо понимать - обычная работа, где схема по указанному вопросу проще схемы загрузки небольшого приложения во много раз.
А обучение - это про другое. Всё это математика, принципиально новые подходы, просто большой объём алгоритмической информации. И всё это завязано в языках, фреймворках, схемах, статьях, безотносительно текущей работы. Когда это понадобится? Может даже и никогда, а может ещё вчера.
Это безотносительно рынка. Одна и та же задача одного качества стоит по разному на разных стеках. Для типовых задач по российскому правовому полю 1С отлично подходит. Но иногда, когда нужно сделать что-то сверх базы, то ценник резко растёт в космос. И не из-за того, что задача имеет сложную программу, ведь так споткнуться можно даже на банальном.
О качестве архитектуры говорит уже выбор типизации. Изначально язык рассчитывался как лёгкий скриптовый, для небольших задач. Но постепенно задачи росли, а язык тот же в основе. Как и многие прочие аспекты платформы.
Это переводится так:
Когда потребуется работа не из "коробки", то это будет стоить х10 от обычной стоимости. А по такой стоимости это либо критично важно и делаем, либо и не нужно вообще, жрите что дали)
C#, Java, Delphi
А так же это значит, что деньги, достаточные для 5G, уйдут на 4G, но по цене 5G.
А меж тем в СПб не так давно был только 1 компонент вакцины доступен
Один из вариантов — обычный подход Unity3D(в посте очень похожий подход, создаётся впечатление, что именно оттуда и содран) с контейнерами в компонентах. Некоторые данные, которые требуют большого количества операций в кадр в компонентах заносились в списки и обрабатывались отдельно для каждого списка(вот это похоже на ECS). И по мне так это много лучше, чем переделывать весь проект под DO, т.к. у ECS тоже есть проблемы, в т.ч. с производительностью.
Одна из проблем ECS — много независимого различного кода, выполняемого за цикл небольшое количество раз. Да, делать перемещение и отрисовку с 10к объектами и парой методов ECS даёт огромный прирост производительности, а вот с 10к методами работать это будет как тот же Update. Другая проблема — писать код для разовых действий. Интерфейсы на ECS? Конечно можно, но зачем? Получается множество контейнеров данных(объектов, компонентов), где рабочий набор всегда один. А это ни чуть не лучше ситуации с Update по производительности, а по сложности написания кода много сложнее.
Только пока это короткая ситуация. При условиях уже высокой информатизации выгоднее один программист-бухгалтер, чем 10 бухгалтеров. Вся экономика перестаёт развиваться и работает больше не на новое, а на поддержку старого, с минимумом изменений и риска. В таком случае часто ИТ-шники на поддержке всё так же очень нужны, нужнее любого балласта(в этих условиях) из маркетологов, продактов и т.д. Но не нужны любые стартапы, игры, развлечения в целом.
Несколько ошибок. Надо считать все условия, собирая комбо - вышка, ИТ, акредитация, обеспечение инфраструктуры, внедрение/разработка.
Чтобы норма работала нужен не ТГ, а акт, закон и прочее(да ещё не всякий).
На сколько смог выяснить, для получения отсрочки! организации нужно подавать списки. В списках нет, забыли подать, попутали и всё равно позвали? Ну когда-нить разберутся, а пока они заняты, вали куда сказали.
У вас не совсем корректные представления о цене жизни в Мск и СпБ.
300к это ниочём. Для хорошей квартиры не в центре, а в середине города, нужно 50+ млн. Такое легко могут себе позволить только некоторые бизнесмены, ну и чиновники.
Чтобы стать подходящим под категорию A необходимо немного опыта. А после получения этого опыта, A от B отличается только непосредственным руководством, ну и доступом ко всей необходимой инфе)
Премия отдельным приказом - право. Премия записанная в ТД - обязанность. Даже чтобы после правильного составления положения, лишить премии, должны быть проведены соответствующие действия, которые явно покажут причины, которые приведут к потере премии. Постфактум лишить премии не получится. Так же нельзя будет лишить возможности её получения просто отгородив работника от работы.
Вообще, можно добиться лишения премии, только вот не дешевле ли будет заплатить по итогу?
В принципе можно. Писать тесты отправить, к примеру.
Но если смотреть именно о задачах программирования, то это всегда новая задача, не похожая при первом приближении на прошлые. Это сами по себе задачи которые не поддаются простой автоматизации, т.к. если поддаются, то эта автоматизация и есть задача.
Не для стажёров, настолько, что если это может сделать стажёр - значит это можно автоматизировать и заменить другим спецом(тестером, админом, манагером, техподдержкой и прочими).
С джунами получше, но они крайне неудобны. Там где мидлу надо поставить задачу в 10 слов, для джуна надо писать абзац или страницу, в которых он ещё и запутается, либо поддерживать и проверять по ходу, а лучше всё вместе. Получается, что задачу именно по разработке в нужном качестве джун не выполнит сам в большинстве случаев. Т.е. можно дать только те задачи, которые вполне автоматизируются, но на которые нет времени, или жалко его тратить. Ну или по принципу применения - дать обособленную вещь, которую в случае проблем проще переписать, чем править и следить в большей части за рамками работы. Но так не достичь высокой эффективности.
В соседней ветке был пример с DTO - это вообще мелочь по времени, больше возьни с объяснением что и для чего это и как этим правильно пользоваться, да и зачем. Для мидла это минуты, а для джуна - часы. Хотя тут и можно применить, только вот и это автоматизируется аж несколькими способами.
А когда натаскаешь он будет уже мидлом)
И ещё одна вещь - с сеньорами можно обсуждать программу свободно, не касаясь языка программирования вообще.
Алгоритмы тоже не являются программами, примерно как наваленная груда кирпича ещё не здание)
Оказалось, самое сложное - доносить о том, что надо писать программы, а не код или алгоритмы. И исходить надо при проектировании из программы, используя алгоритмы и код лишь как инструменты. Не редко выходит иначе даже после 5 лет работы программистом.