Так я может не хочу отписываться каждый раз при destroy моего компонент, может мне нужно подписаться в какой-то момент и больше не отписываться. Если я пишу приложение на условном Angular - то это как правило SPA, оно может жить месяцами в открытом окне/табе без обновления страницы. И все это время подписка может жить, и это expected behaviour
А к чему вы устроили это цирковое представление? В вашем примере вы просто ссылаетесь на асинхронный метод $mol_fetch.json() , это далеко не то же самое, как работают Observables в библиотеке rxjs. Если это какая-то насмешка над Ангуляром, то смею вас заверить, что его компоненты тоже никакого понятия о rxjs не имеют и никакого встроенного механизма автоматических отписок (которые могут быть еще и не желательны в отдельных случаях) не имеют. Не нравится rxjs - никто не запрещает использовать любую другую библиотеку или дефолтный fetch. А логика вида "подписался на что-то -- отпишись" справедлива для всего, при работе с асинхронным кодом.
Я кстати не совсем уверен, как это обходится в ситуации различного инди-шлака. Вероятнее всего, есть какие-то издатели с две-китами на руках, готовые помочь издать любой шлак, который только может пройти проверку Сони или Нинтендо. Таким образом, оформление офиса и закупка дев-китов становится необязательным условием, при наличии подобных издателей.
А вы давно заглядывали в ps-store и Nintendo online? Если пройти дальше красивой главной страницы в каталог и поставить сортировку по "дате добавления", то вы увидите, что инди там сейчас не меньше, чем в Стиме, порой все тот же треш, уровня "визуальная новелла про свидания с голубями". И даже контроль качества отсутствует, попадаются проекты которые настолько плохо сделаны, что вылетают на определенном этапе игры и не дают себя пройти.
Насчёт дружелюбия, полагаю, Сони и Нинтендо сегодня позволяют почти любому инди-разрабу добавлять свои проекты с минимальной проверкой контента. А для сам их разрабов — это просто кнопка "собрать билд для PS/Switch" в Unity.
Ну в каком-то смысле поработили, я лично не знаю ни одного человека, у которого бы сегодня не было телефона и кто бы не использовал его ежедневно. Ездил в командировку в Бутан, в далеких горных монастырях за километры от привычной цивилизации, монахи, в свободное от молитв и обучения время, смотрят видосы на ютубе и втыкают в тик-ток.
Ну примерно как при изобретении фотоаппарата. Были ведь тогда опасения, что художники останутся никому не нужны. А по факту, художники никуда не делись, так как ценен сам факт того, что изобразительному искусству сложно обучиться, на это надо потратить годы и что далеко не каждый готов потратить эти годы.
Я видел сегодня твит, что у них (сам не проверял): сайт сделан в no-code редакторе, запись на бету осуществляется через гугл-форму, а в вакансиях числится "software engineer". Вот такой вот полный цикл разработки "босой сапожник".
Очень часто базовый автокомплит IDE справляется лучше, чем Copilot, так как последний грешит тем, что придумывает какие-то свои свойства и методы, которых даже близко нет в базовом классе. И иногда ты тратишь на ревью одной строчки кода больше времени, чем написал бы сам по-старинке. При этом бывает конечно и обратное, когда ему удается сгенерировать сравнительно большой кусок кода и ты думаешь "вау, как круто, сколько времени сэкономил". И такие качели постоянно. Примерно как парное программирование с джуном, никакой самостоятельности, непрерывный code review.
Млрд ФПС? Не помню, чтобы видел хотя бы четырехзначное число ФПС даже на программках тупо отрисовывающих один треугольник. Не поделитесь ссылкой на такой бенчмарк, мне правда интересно?
Про тормозящее 2д, тут на самом деле все очень просто. Недавно игрался с юнити, делал простенькую сцену, типа 3в-ряд или пятнашек, Первое решение в лоб - каждая клетка была цветным пикселем PNG-файла, и представляла собой префаб с одним коллайдером2д, спрайтом и дочерним объектом, выводящим текст (просто циферку). Когда поле было маленькое, 16х16 - никаких проблем, значение фпс прыгало от 300 до 500 в 1080p, но стоило для теста изменить на картинку 100х100 - как фпс упал до неиграбельных 10-15. Хотя казалось бы, на экране не происходит вообще ничего, просто выводится сетка из 10к префабов с цифрами.
Мой комментарий не столько про готовые или собственные движки, сколько про разделение задач и ответственности. В соло или маленькой команде скорее всего придется заниматься многими вещами далекими от разработки как таковой, в большой компании (даже использующей готовый движок) могут просто посадить за узкую задачу, типа отдельный редактор квестов или игровой карты, при этом ни байта твоего кода по сути в самой игре и не будет. Будешь ли ты при этом счастлив или нет - вопрос который каждый должен задать себе сам, прежде чем идти в геймдев.
Если программист именно хочет заниматься программированием, то идти работать в гейм-дев компанию, мне кажется, было бы неплохим решением. Плохим решением было бы идти на вольные хлеба в соло-инди-дев. У меня есть небольшой опыт подобного, по факту получилось что именно программирования (создания С# скриптов для юнити) оказалось дай бог если 5% от всей работы. Остальное время заняло: проектирование, создание сцен в редакторе, рисование графики и арта, поиск всевозможных звуков и музыки (поиск бесплтаного, покупка недорогого или создание с нуля в редакторах музыки), локализация, тестирование и отладка. На закуску: издательство и маркетинг. В момент когда к тебе приходит идея и ты тестируешь какую-то интересную геймплейную фичу, ты в этот момент даже не задумываешься, сколько времени может уйти просто на то чтобы настроить и оформить свою страницу на каком-нибудь маркетплейсе, типа стима и внедрить их оверлей в свою игру с ачивками и прочими плюшками (программирования там опять же по минимуму, все уже написано для вас, в основном это конфигурирование сборок).
С take(1) тоже надо отписываться в обязательном порядке, так как если в течение жизни компонента ни одного значения не придет — вы все ещё останетесь на него подписаны
Не хотел бы обесценивать труд всех этих людей, но я почему-то не совсем понимаю почему кранчить пришлось именно на этом проекте. Так как, как геймер, не вижу значительной разницы между Just Dance 2023 и 2022, кроме самого набора песен.
Нет, не обязательно около садового. Но вот когда я переезжал, у меня было понимание, что офисы большинства IT-компаний будут сосредоточены внутри ТТК. Соответственно, поиск жилья осуществляется с расчетом, чтобы поселиться как можно ближе к ТТК и чтобы время в пути на метро от дома до почти любой точки внутри ТТК укладывалось примерно в 1 час. Не так, что все IT-компании снимают офисы в Мытищах, а мы ищем квартиру на Теплом Стане.
Для исследовательской работы маловато выводов. Хотелось бы больше деталей о сложности самих алгоритмов, о методах их оптимизации, о вариантах применения не просто в духе "результат похож на шерсть поэтому сгодится для текстуры шерсти", а конкретно, какие параметры генерации на что влияют или, например, рассмотреть какие варианты местностей можно сгенерировать каждым из алгоритмов.
Я как-то на крыльце своего подъезда встретил, сразу убежала. Но вообще, по вечерам, их много в нашем районе, охотятся на мышей, выглядывающих из решеток ливневок.
Да и в целом использование библиотеки RxJS не является обязательным условием для работы с данным фреймворком. Если оно по какой-то причине не устраивает или просто не нравится, то можно прекрасно обойтись без нее.
"Они позволяют сэкономить огромное количество байт памяти при создании крупномасштабного приложения, посещаемого тысячами пользователей." - странная фраза, огромное количество байт - это сколько? 100? 1000? 1000000 байт? И при чем тут крупномасштабность приложения и количество его пользователей, если, как правило, код выполняется на клиенте?
"Async Pipes — это встроенные атрибуты." - что за встроенные атрибуты? Это обычный Angular Pipe, упрощающий работу с Observables.
"Не сортируйте и не фильтруйте данные в пайпе" - в целом, зависит от примера использования, если массивы мелкие и changeDetection установлен в OnPush - то не так уж страшно.
"Используйте NgIf, а не CSS" - может быть вредным советом, часто куда проще и производительнее скрыть какой-то компонент с помощью CSS, чем каждый раз создавать новый и позволять ему проходить новый lifecycle
"Используйте index.ts" - к Angular-у совет отношение не имеет, это уже косметика на уровне TypeScript. Хотите пути еще короче - объявите их в config-e в разделе path https://www.typescriptlang.org/tsconfig#paths
У меня такой вес показывает когда кошка только передними лапами встаёт и заглядывает внутрь, понюхать как там, но целиком не запрыгивает
Так я может не хочу отписываться каждый раз при destroy моего компонент, может мне нужно подписаться в какой-то момент и больше не отписываться. Если я пишу приложение на условном Angular - то это как правило SPA, оно может жить месяцами в открытом окне/табе без обновления страницы. И все это время подписка может жить, и это expected behaviour
А к чему вы устроили это цирковое представление? В вашем примере вы просто ссылаетесь на асинхронный метод
$mol_fetch.json(), это далеко не то же самое, как работают Observables в библиотеке rxjs. Если это какая-то насмешка над Ангуляром, то смею вас заверить, что его компоненты тоже никакого понятия о rxjs не имеют и никакого встроенного механизма автоматических отписок (которые могут быть еще и не желательны в отдельных случаях) не имеют. Не нравится rxjs - никто не запрещает использовать любую другую библиотеку или дефолтный fetch. А логика вида "подписался на что-то -- отпишись" справедлива для всего, при работе с асинхронным кодом.Я кстати не совсем уверен, как это обходится в ситуации различного инди-шлака. Вероятнее всего, есть какие-то издатели с две-китами на руках, готовые помочь издать любой шлак, который только может пройти проверку Сони или Нинтендо. Таким образом, оформление офиса и закупка дев-китов становится необязательным условием, при наличии подобных издателей.
А вы давно заглядывали в ps-store и Nintendo online? Если пройти дальше красивой главной страницы в каталог и поставить сортировку по "дате добавления", то вы увидите, что инди там сейчас не меньше, чем в Стиме, порой все тот же треш, уровня "визуальная новелла про свидания с голубями". И даже контроль качества отсутствует, попадаются проекты которые настолько плохо сделаны, что вылетают на определенном этапе игры и не дают себя пройти.
Насчёт дружелюбия, полагаю, Сони и Нинтендо сегодня позволяют почти любому инди-разрабу добавлять свои проекты с минимальной проверкой контента. А для сам их разрабов — это просто кнопка "собрать билд для PS/Switch" в Unity.
Ну в каком-то смысле поработили, я лично не знаю ни одного человека, у которого бы сегодня не было телефона и кто бы не использовал его ежедневно. Ездил в командировку в Бутан, в далеких горных монастырях за километры от привычной цивилизации, монахи, в свободное от молитв и обучения время, смотрят видосы на ютубе и втыкают в тик-ток.
Ну примерно как при изобретении фотоаппарата. Были ведь тогда опасения, что художники останутся никому не нужны. А по факту, художники никуда не делись, так как ценен сам факт того, что изобразительному искусству сложно обучиться, на это надо потратить годы и что далеко не каждый готов потратить эти годы.
Я видел сегодня твит, что у них (сам не проверял): сайт сделан в no-code редакторе, запись на бету осуществляется через гугл-форму, а в вакансиях числится "software engineer". Вот такой вот полный цикл разработки "босой сапожник".
Очень часто базовый автокомплит IDE справляется лучше, чем Copilot, так как последний грешит тем, что придумывает какие-то свои свойства и методы, которых даже близко нет в базовом классе. И иногда ты тратишь на ревью одной строчки кода больше времени, чем написал бы сам по-старинке. При этом бывает конечно и обратное, когда ему удается сгенерировать сравнительно большой кусок кода и ты думаешь "вау, как круто, сколько времени сэкономил". И такие качели постоянно. Примерно как парное программирование с джуном, никакой самостоятельности, непрерывный code review.
Млрд ФПС? Не помню, чтобы видел хотя бы четырехзначное число ФПС даже на программках тупо отрисовывающих один треугольник. Не поделитесь ссылкой на такой бенчмарк, мне правда интересно?
Про тормозящее 2д, тут на самом деле все очень просто. Недавно игрался с юнити, делал простенькую сцену, типа 3в-ряд или пятнашек, Первое решение в лоб - каждая клетка была цветным пикселем PNG-файла, и представляла собой префаб с одним коллайдером2д, спрайтом и дочерним объектом, выводящим текст (просто циферку). Когда поле было маленькое, 16х16 - никаких проблем, значение фпс прыгало от 300 до 500 в 1080p, но стоило для теста изменить на картинку 100х100 - как фпс упал до неиграбельных 10-15. Хотя казалось бы, на экране не происходит вообще ничего, просто выводится сетка из 10к префабов с цифрами.
Мой комментарий не столько про готовые или собственные движки, сколько про разделение задач и ответственности. В соло или маленькой команде скорее всего придется заниматься многими вещами далекими от разработки как таковой, в большой компании (даже использующей готовый движок) могут просто посадить за узкую задачу, типа отдельный редактор квестов или игровой карты, при этом ни байта твоего кода по сути в самой игре и не будет. Будешь ли ты при этом счастлив или нет - вопрос который каждый должен задать себе сам, прежде чем идти в геймдев.
Если программист именно хочет заниматься программированием, то идти работать в гейм-дев компанию, мне кажется, было бы неплохим решением. Плохим решением было бы идти на вольные хлеба в соло-инди-дев. У меня есть небольшой опыт подобного, по факту получилось что именно программирования (создания С# скриптов для юнити) оказалось дай бог если 5% от всей работы. Остальное время заняло: проектирование, создание сцен в редакторе, рисование графики и арта, поиск всевозможных звуков и музыки (поиск бесплтаного, покупка недорогого или создание с нуля в редакторах музыки), локализация, тестирование и отладка. На закуску: издательство и маркетинг. В момент когда к тебе приходит идея и ты тестируешь какую-то интересную геймплейную фичу, ты в этот момент даже не задумываешься, сколько времени может уйти просто на то чтобы настроить и оформить свою страницу на каком-нибудь маркетплейсе, типа стима и внедрить их оверлей в свою игру с ачивками и прочими плюшками (программирования там опять же по минимуму, все уже написано для вас, в основном это конфигурирование сборок).
С take(1) тоже надо отписываться в обязательном порядке, так как если в течение жизни компонента ни одного значения не придет — вы все ещё останетесь на него подписаны
Не хотел бы обесценивать труд всех этих людей, но я почему-то не совсем понимаю почему кранчить пришлось именно на этом проекте. Так как, как геймер, не вижу значительной разницы между Just Dance 2023 и 2022, кроме самого набора песен.
Ага, тоже не понимаю. Или ему на курсах по окончанию сразу обещали позицию сеньора с зп сеньора?
Нет, не обязательно около садового. Но вот когда я переезжал, у меня было понимание, что офисы большинства IT-компаний будут сосредоточены внутри ТТК. Соответственно, поиск жилья осуществляется с расчетом, чтобы поселиться как можно ближе к ТТК и чтобы время в пути на метро от дома до почти любой точки внутри ТТК укладывалось примерно в 1 час. Не так, что все IT-компании снимают офисы в Мытищах, а мы ищем квартиру на Теплом Стане.
Для исследовательской работы маловато выводов. Хотелось бы больше деталей о сложности самих алгоритмов, о методах их оптимизации, о вариантах применения не просто в духе "результат похож на шерсть поэтому сгодится для текстуры шерсти", а конкретно, какие параметры генерации на что влияют или, например, рассмотреть какие варианты местностей можно сгенерировать каждым из алгоритмов.
Я как-то на крыльце своего подъезда встретил, сразу убежала. Но вообще, по вечерам, их много в нашем районе, охотятся на мышей, выглядывающих из решеток ливневок.
Да и в целом использование библиотеки RxJS не является обязательным условием для работы с данным фреймворком. Если оно по какой-то причине не устраивает или просто не нравится, то можно прекрасно обойтись без нее.
"Они позволяют сэкономить огромное количество байт памяти при создании крупномасштабного приложения, посещаемого тысячами пользователей." - странная фраза, огромное количество байт - это сколько? 100? 1000? 1000000 байт? И при чем тут крупномасштабность приложения и количество его пользователей, если, как правило, код выполняется на клиенте?
"Async Pipes — это встроенные атрибуты." - что за встроенные атрибуты? Это обычный Angular Pipe, упрощающий работу с Observables.
"Не сортируйте и не фильтруйте данные в пайпе" - в целом, зависит от примера использования, если массивы мелкие и changeDetection установлен в OnPush - то не так уж страшно.
"Используйте NgIf, а не CSS" - может быть вредным советом, часто куда проще и производительнее скрыть какой-то компонент с помощью CSS, чем каждый раз создавать новый и позволять ему проходить новый lifecycle
"Используйте index.ts" - к Angular-у совет отношение не имеет, это уже косметика на уровне TypeScript. Хотите пути еще короче - объявите их в config-e в разделе path https://www.typescriptlang.org/tsconfig#paths