Я видел сегодня твит, что у них (сам не проверял): сайт сделан в 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
"Использование take(1)" - тут надо быть осторожным, это не замена unsubscribe. Если вы подпишитесь на Observable и передадите в .pipe(take(1)), то если он в ходе жизни вашего компонента не передаст ни одного значения, вы все еще останетесь на него подписанным, даже если компонент будет уничтожен. Надежнее использовать unsubscribe() или takeUntil().
Да, но тут опять же "мне повезло познакомиться с влиятельным человеком" - это то, чем можно управлять. Если есть Вася - замкнутый, редко выходит из дома и вообще уехал жить в маленькую деревню в Сибири - какие у него шансы познакомиться с влиятельным человеком? Они все еще не нулевые, но близки к тому. Или Петя, активно работающий над наращиванием социального капитала, не пропускающим ни одной конференции или иных тусовок, ведущий активную деятельность в социальных сетях - всеми своими действиями приближающий себя к знакомству с влиятельными людьми.
Я читал историю про человека, который посвятил себя посещению тусовок со всякими чиновниками, арендовал себе костюмы и машину с водителем чтобы выглядеть солиднее, постил потом в свой блог со словами "вот я пожимаю руку мэру города N", и в конце концов так примелькался, что смог получить какую-то важную должность в итоге. Без пруфов, извините, не помню источник, возможно это и был литературный вымысел, но я вполне допускаю, что такое могло произойти на самом деле.
По поводу счастливой случайности, я считаю, тоже есть над чем подумать и как научиться управлять этой самой случайностью. Представьте, Вася и Петя разработчики примерно с одинаковым опытом мечтают получить оффер в гугл, оба подают свои резюме, проходят собеседования и первый получает отказ, а второй проходит. Вася начинает всем говорить "да Пете просто повезло, а меня завалили, я неудачник, мне всегда не везет" и перестает делать дальнейшие попытки получить оффер. При этом, Вася никак не готовился к собеседованию, а Петя изучал статьи от других людей, кто уже получил свой оффер, решал задачки на литкоде, тренировал речь и т.д. То есть много работал над тем, чтобы увеличить свои шансы на успех и уменьшить элемент "случайности".
Так и в бизнесе, мы на самом деле когда говорим "бизнесмен Олег счастливчик, ему просто повезло, а все остальные делали то же самое, но у них ничего не получилось" - мы на самом деле не знаем, был ли это действительно счастливый случай или долгая кропотливая подготовка до.
Не понял, почему 4 зарплаты? Типа, при увольнении вам обязаны были бы выплатить 3 зарплаты сверху? Но ведь испытательный срок на то и испытательный срок, что на нем можно расстаться с сотрудником без всяких условий.
Одно дело, если вы 10 лет учились в школе чтобы поступить в институт, потом 5-6 лет учились в институте и работали потом 10-15 лет, чтобы сегодня называться "сеньором разработчиком" и получать достойную для потраченных на учебу лет зп. И тут вам говорят: "ваши услуги больше не нужны, перепрофилируйтесь и обучайтесь заново". И совсем другое дело, когда вы вчера научились чистить трубы.
Я вам еще раз говорю, что терапия просто так не работает, а вы опять пишите о том, в чем совершенно не разбираетесь. Вы не проходили личную терапию, просто пытаетесь придумать сценарии, при которых вы могли бы оказаться правым, да еще (зачем-то) убедить меня. Ни один специалист на терапии не будет давать вам советы, которые могут привести к разрыву отношений. Если перед вами терапевт, который дает советы - это не терапевт, бегите от него. Приводят ли походы на личную терапию к разрывам отношений и разводам - да, конечно, люди часто начинают видеть свою жизнь по другому и выходят из вредных для себя отношений. Вина ли это терапевта или терапии? Был ли причинен вред пациенту? Нет, конечно) Является ли "невротическое поведение" каким-то отклонением от нормы? Нет) Невротиков в мире подавляющее большинство, это фактически и есть норма. Вот встретить полностью здорового человека без невроза - вот это у вас скорее всего не получится.
Я видел сегодня твит, что у них (сам не проверял): сайт сделан в 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
"Использование take(1)" - тут надо быть осторожным, это не замена unsubscribe. Если вы подпишитесь на Observable и передадите в .pipe(take(1)), то если он в ходе жизни вашего компонента не передаст ни одного значения, вы все еще останетесь на него подписанным, даже если компонент будет уничтожен. Надежнее использовать unsubscribe() или takeUntil().
Ну и следите за обновлениями, начиная с Angular 16, можно использовать .pipe(takeUntilDestroyed());
https://blog.angular.io/angular-v16-is-here-4d7a28ec680d
Да, но тут опять же "мне повезло познакомиться с влиятельным человеком" - это то, чем можно управлять. Если есть Вася - замкнутый, редко выходит из дома и вообще уехал жить в маленькую деревню в Сибири - какие у него шансы познакомиться с влиятельным человеком? Они все еще не нулевые, но близки к тому. Или Петя, активно работающий над наращиванием социального капитала, не пропускающим ни одной конференции или иных тусовок, ведущий активную деятельность в социальных сетях - всеми своими действиями приближающий себя к знакомству с влиятельными людьми.
Я читал историю про человека, который посвятил себя посещению тусовок со всякими чиновниками, арендовал себе костюмы и машину с водителем чтобы выглядеть солиднее, постил потом в свой блог со словами "вот я пожимаю руку мэру города N", и в конце концов так примелькался, что смог получить какую-то важную должность в итоге. Без пруфов, извините, не помню источник, возможно это и был литературный вымысел, но я вполне допускаю, что такое могло произойти на самом деле.
По поводу счастливой случайности, я считаю, тоже есть над чем подумать и как научиться управлять этой самой случайностью. Представьте, Вася и Петя разработчики примерно с одинаковым опытом мечтают получить оффер в гугл, оба подают свои резюме, проходят собеседования и первый получает отказ, а второй проходит. Вася начинает всем говорить "да Пете просто повезло, а меня завалили, я неудачник, мне всегда не везет" и перестает делать дальнейшие попытки получить оффер. При этом, Вася никак не готовился к собеседованию, а Петя изучал статьи от других людей, кто уже получил свой оффер, решал задачки на литкоде, тренировал речь и т.д. То есть много работал над тем, чтобы увеличить свои шансы на успех и уменьшить элемент "случайности".
Так и в бизнесе, мы на самом деле когда говорим "бизнесмен Олег счастливчик, ему просто повезло, а все остальные делали то же самое, но у них ничего не получилось" - мы на самом деле не знаем, был ли это действительно счастливый случай или долгая кропотливая подготовка до.
Не понял, почему 4 зарплаты? Типа, при увольнении вам обязаны были бы выплатить 3 зарплаты сверху? Но ведь испытательный срок на то и испытательный срок, что на нем можно расстаться с сотрудником без всяких условий.
Одно дело, если вы 10 лет учились в школе чтобы поступить в институт, потом 5-6 лет учились в институте и работали потом 10-15 лет, чтобы сегодня называться "сеньором разработчиком" и получать достойную для потраченных на учебу лет зп. И тут вам говорят: "ваши услуги больше не нужны, перепрофилируйтесь и обучайтесь заново". И совсем другое дело, когда вы вчера научились чистить трубы.
Сразу подумалось о фильме-антиутопии "Бразилия" Терри Гиллиама.
Я вам еще раз говорю, что терапия просто так не работает, а вы опять пишите о том, в чем совершенно не разбираетесь. Вы не проходили личную терапию, просто пытаетесь придумать сценарии, при которых вы могли бы оказаться правым, да еще (зачем-то) убедить меня. Ни один специалист на терапии не будет давать вам советы, которые могут привести к разрыву отношений. Если перед вами терапевт, который дает советы - это не терапевт, бегите от него. Приводят ли походы на личную терапию к разрывам отношений и разводам - да, конечно, люди часто начинают видеть свою жизнь по другому и выходят из вредных для себя отношений. Вина ли это терапевта или терапии? Был ли причинен вред пациенту? Нет, конечно) Является ли "невротическое поведение" каким-то отклонением от нормы? Нет) Невротиков в мире подавляющее большинство, это фактически и есть норма. Вот встретить полностью здорового человека без невроза - вот это у вас скорее всего не получится.