Продолжу перечислять пункты моего категорического несогласия:
В ЗП айтишника нет ничего экстраординарного, а для владельца малого бизнеса нет ничего сверхъестественного, чтобы зарабатывать столько же. Особенно если твой малый бизнес тоже в IT.
А зачем вообще дорастать до оборота в миллиард рублей? Кому он вообще нужен? Обороты не являются мерилом успешности бизнеса.
Вообще в целом деньгоориентированность ваших постов не находит у меня отклика. И реально не одной зарплатой всё решается в жизни. Моя компания успешна, если позволяет мне жить так, как я хочу, и заниматься тем, чем мне интересно. Даже если я могу легко уйти в найм и зарабатывать x10, находясь в корпорации - мне это будет не интересно, потому что остальные мои жизненные запросы закрыты не будут. Можно, конечно рассмеяться в ответ, как раджа из "Золотой антилопы", и сказать, что денег много не бывает, но тогда мы с вами из разных вселенных.
Не могу согласиться с такой тотально безнадёжной картиной для владельца малого бизнеса, хотя в целом сценарий описан верно, такое в жизни тоже случается.
Малому бизнесу, по факту, не нужны те же сотрудники, которые нужны сферическому гугло-яндексу.
Хотя вопрос оценки уровня сотрудника вообще дискуссионный, лично я вообще не считаю, что все разработчики в корпорациях вот прям на голову выше тех, кто работает на малый бизнес. Это во многом вопрос целеустремлённости, амбициозности, жизненных ценностей... ну и умение продать себя. Так ли важны эти качества на проектах малого бизнеса?))) Не думаю.
Поэтому я бы вообще не сказал, что между малым бизнесом и корпорациями есть какая-то конкуренция за кадры. Просто сотрудник рано или поздно вырастет из проектов малого бизнеса, изменятся цели, потребности, интересы и т.п. И он уйдет "выше". Обычный жизненный цикл, который надо просто знать, учитывать и не ныть на тяжёлую судьбу (хотя признаю, хочется).
К слову сказать, бывают случаи и осознанного «дауншифтинга», это, конечно, редкость, но тоже случается. Делать на это ставку не стоит, просто если вам повезло - ну, порадуйтесь.
В общем, пытаться перехватить к себе кого-то, кто сыто и богато жил в корпорации - затея бессмысленная не только потому что вряд ли получится, но и потому что вряд ли вам на самом деле это нужно. Есть подозрение, что такое желание может быть вызвано недостатком собственной компетенции / нежеланием разбираться в проблеме, и, чтобы подавить свою неуверенность, руководство требует, чтобы его сайт на вордпрессе делал сеньёр с 5 годами работы в Яндексе)))))) ну штош... Бедный айчар.
Устройства, конечно, разные бывают, но мне как прилетали все обновления HP через обновления Windows, так и продолжают прилетать. Но да, обновлятор от HR скопытился. Правда, сделал он это ещё в 22 году. В общем, тухлый такой инфоповод.
Не совсем понял, в чем новизна и инновационность, как это можно патентовать: у меня коллега в 2013 году с таким "двусторонним" ноутбуком ходил... говорил, что ему это нужно, чтобы клиентам на встречах было проще демонстрировать экран, не подсаживаясь рядом, не ища проектор и т.п.
Unihertz Atom L. Прямо сейчас 35 вкладок открыто, а ещё я на нем фотки в Raw редактирую в походных условиях. Недостатка оперативы не чувствую, а у меня её "всего лишь" 6 гигов .
Так преподносится, будто нет на свете Unihertz Atom L/XL. А они есть, уже несколько лет как, я вот с такого сейчас пишу. По компактности мой "старичок" новенький Танк уже сделает, т.к. не такой толстый.
Мегапиксили - ни о чем, в мой вот запихано 40, но получается так же мерзко, так и раньше было на 14и. Уверен, что и с фоткой будет не лучше.
К моему текущему Атому вопроса два:
Я за первые 2 года израсходовал ресурс кнопки включения - выключения, теперь она от случайного резкого движения может "нажаться" - и телефон уйдет в циклическую перезагрузку.
Экран. Через 2месяца использования начало проявляться призрачное изображение, особенно если было что-то белое. Меня в основном не парит, но порой фотки мешает шаманить.
Всё остальное у авторов получилось хорошо. На камеру не жалуюсь, потому что она ожидаемо плохая, просто не понимаю, зачем они пыжатся с мегапикселями. Вот если над этими двумя проблемами работали и в новом телефоне такого не случится - тогда стоило бы рассмотреть к покупке, даже несмотря на больший вес и размер. Хотяяя.... Тоже весьма спорно.
Моё личное впечатление: исследование скорее отражает портрет участника сообщества, а не портрет php-разработчика вообще. Как бы прикольно, но какие выводы из этой статистики делать - непонятно. Ну, молодцы, что провели.
Присоединюсь, вот совсем не хочется вас забивать ногами, но у меня в Москве точно такая же проблема с этим чертовым зумом и закрывающимися открытыми окнами, абсолютно на любой версии, на любом телефоне и во все времна, то есть за последние лет 5 минимум. А негодование людей, огребающих чудеса юзабилити на морозе, понятно вдвойне. Отправьте проектировщиков интерфейса в командировку в поля, в самую всратую погоду, пусть вернутся просветлёнными)))
Вот плюсую, статья реально выглядит как агитка в стиле "наших бьют, мы обделены и обижены, всем срочно на баррикады!" - и надёрганы выборочные факты, чтобы вызвать эмоциональную реакцию.
Дело вкуса. Я вот люблю фигурные скобки и ловерКэмэлКейз. А вот КамелКейз меня уже бесит пуще андер_скора. И отступ табами в 8 пробелов вызывает чувство, что олды точно где-то тут.
Но это, конечно, не должно быть критерием для оценки качества кода и языка в целом, везде свои традиции.
В плане расчёта столкновений не вижу разницы для тайловой карты и любой другой... Разве что у вас игровой процесс как в шахматах, объекты строго перемещаются по ячейкам, и сталкивать их непосредственно нет нужды.
бывают сложности с рендерингом, когда карта большая. Пишут костыли, чтобы обойти эту проблему и/или дробят карту. В моем движке можно рендерить карту любого размера
Не совсем так. Размер карты сам по себе не имеет большого значения, важнее количество объектов на ней, которые приходится обсчитывать. Естественно, чтобы запихать больше объектов, нужны бОльшие карты, но это скорее следствие, а не причина.
У вас в примере на codepen я действительно увидел карту с небольшим числом объектов, с которыми современные процессоры (то есть наверное всё, что выпущено за последние 10 лет) могут справится простым перебором. А вот если объектов будет на порядки больше, то уже и самому топовому железу придётся не сладко. А уж тем более если расчёты идут на JS и в один поток (игнорируется наличие многаядер, работать будет только одно).
Можно провести простой эксперимент: сделайте такую карту, чтобы на ней было хотя бы 10 000 отдельных объектов, для которых считаются коллизии.
Ну в этом-то как раз ничего удивительного, я тоже зарабатываю сильно меньше разраба из финтеха или любого руководителя из корпорации. В собственной компании есть другие плюсы, если удалось правильно её "приготовить".
Другое дело, что хотелось бы услышать "раскрытие тайных знаний" не от какого-то среднестатистического хрена, а от человека, у которого действительно ПОЛУЧИЛОСЬ, вот прям с большой буквы. Так-то бизнесы открывают и держат на плаву много кто.
Сотня объектов - это уже много для системы, которая определяет столкновения перебором всего. У меня и на десктопе тормозило на меньшем числе. пришлось сначала написать QuadTree, но потом и его стало мало. Так что тут однозначно надо как-то резать пространство.
Даже если все ячейки пространства придётся держать активными - всё равно будет буст непосредственно при расчёте столкновения, т.к. выборка объектов будет ограничена. То, что я у себя "выключаю" ячейки, которые далеко от игрока или не в зоне видимости - это уже из области "сопутствующей оптимизации", и непосредственно к столкновениям отношения не имеет. Просто раз появилась возможность переиспользовать сделанные вычисления для чего-то ещё - то почему бы и нет.
Плюсую. А то ведь у меня тоже есть какая-то стратегия, идущая вразрез с принятой у технологических гигантов, и я могу о ней рассказать. И у оренбуржского разработчика Василия Помидорова есть. И у саратовского тимлида Николая Главнюкова.... Давайте срочно все выйдем и раскроем свои удивительные стратегии, а то ведь весь мир мучается в догадках и спать не может без этого знания...
Пока из интересного - только обманутые ожидания. Я-то думал, у него фамилия Борщ. А оказалось - просто банальный Борх, вот скукота-то....
Хммм, на днях запилил похожее для своего велосипеда, каждый объект в состоянии взаимодействия с другим взаимодействующим объектом отсылает ему список доступных экшенов на выбор, ломать, юзать, экипировать или что там ещё... Даже не подозревал, что это может быть реализовано так, что тормоза будут не при взаимодействии с объектом (у меня там, признаться, дофига абстракций, которые, уверен, дают ощутимый оверхэд), а просто при заходе на уровень =\
Я правильно понял, что ему передается компонент, движение которого надо отслеживать?
Да, почти так. Ну, я передаю ему не сам объект, а хитбокс объекта, для которого движок всё равно на каждом цикле будет расчитывать абсолютную позицию относительно мира, чтобы не делать эти вычисления повторно.
У SpatialGrid именно в том и суть, что мы можем отсекать большие группы объектов из работы над столкновениями, и не пробегаться по всем фрагментам игрового мира, а брать только активные. Поэтому тут однозначно HashMap, а не списки, т.к. предполагается, что ячеек очень-очень много и итерация по всем ним будет однозначно дольше, чем медленный доступ по ключу.
Хотя, я тут недавно разбирал, что можно в ряде случаев HashMap переписать на циклы, но в ходе профилирования у меня никогда не возникало случая, чтобы тормозил именно этот доступ по ключу. Уверен, на каком бы языке вы ни писали, это не станет узким местом. Уж меня Dart совсем не балует беспрецедентной скоростью работы, так что если бы в коде что-то тормозило - это точно сразу стало бы видно.
Но надо заметить, что всё зависит от игры: если у вас RPG, и в центре внимания персонаж, то можно замораживать или откладывать расчёты по фрагментам мира, которые находятся достаточно далеко от него. Если же это, скажем, RTS, то придётся одинаков скрупулёзно расчитывать события на всех участках карты - и тогда уже от итерации по всему списку никуда не деться.
Можно либо полезть в исходники Skia и посмотреть, что же она делает с картинками под капотом, получить некое знание, и жить с ним дальше, т.к. повлиять на этот процесс всё равно не получится на уровне Dart. Мы просто сможем сказать "да, всё плохо" или "да забейте, всё хорошо".
Либо не разрабатывать свой продукт на инструментах, не дающих такого детального контроля, раз для продукта так критично даже то, в каком формате файлы улетают.
На уровне языка Dart есть только разделение на растризованную картинку и объект с записанными командами отрисовки. Всё. Не важно, грузим мы в Flutter jpg, png, bitmap или поток байтов со звуковой карты :-) В конечном итоге он пойдёт на видеокарту либо в одном либо в другом формате, и на то, что у этих форматов под капотом мы никак воздействовать не можем.
Продолжу перечислять пункты моего категорического несогласия:
В ЗП айтишника нет ничего экстраординарного, а для владельца малого бизнеса нет ничего сверхъестественного, чтобы зарабатывать столько же. Особенно если твой малый бизнес тоже в IT.
А зачем вообще дорастать до оборота в миллиард рублей? Кому он вообще нужен? Обороты не являются мерилом успешности бизнеса.
Вообще в целом деньгоориентированность ваших постов не находит у меня отклика. И реально не одной зарплатой всё решается в жизни. Моя компания успешна, если позволяет мне жить так, как я хочу, и заниматься тем, чем мне интересно. Даже если я могу легко уйти в найм и зарабатывать x10, находясь в корпорации - мне это будет не интересно, потому что остальные мои жизненные запросы закрыты не будут. Можно, конечно рассмеяться в ответ, как раджа из "Золотой антилопы", и сказать, что денег много не бывает, но тогда мы с вами из разных вселенных.
Не могу согласиться с такой тотально безнадёжной картиной для владельца малого бизнеса, хотя в целом сценарий описан верно, такое в жизни тоже случается.
Малому бизнесу, по факту, не нужны те же сотрудники, которые нужны сферическому гугло-яндексу.
Хотя вопрос оценки уровня сотрудника вообще дискуссионный, лично я вообще не считаю, что все разработчики в корпорациях вот прям на голову выше тех, кто работает на малый бизнес. Это во многом вопрос целеустремлённости, амбициозности, жизненных ценностей... ну и умение продать себя. Так ли важны эти качества на проектах малого бизнеса?))) Не думаю.
Поэтому я бы вообще не сказал, что между малым бизнесом и корпорациями есть какая-то конкуренция за кадры. Просто сотрудник рано или поздно вырастет из проектов малого бизнеса, изменятся цели, потребности, интересы и т.п. И он уйдет "выше". Обычный жизненный цикл, который надо просто знать, учитывать и не ныть на тяжёлую судьбу (хотя признаю, хочется).
К слову сказать, бывают случаи и осознанного «дауншифтинга», это, конечно, редкость, но тоже случается. Делать на это ставку не стоит, просто если вам повезло - ну, порадуйтесь.
В общем, пытаться перехватить к себе кого-то, кто сыто и богато жил в корпорации - затея бессмысленная не только потому что вряд ли получится, но и потому что вряд ли вам на самом деле это нужно. Есть подозрение, что такое желание может быть вызвано недостатком собственной компетенции / нежеланием разбираться в проблеме, и, чтобы подавить свою неуверенность, руководство требует, чтобы его сайт на вордпрессе делал сеньёр с 5 годами работы в Яндексе)))))) ну штош... Бедный айчар.
Устройства, конечно, разные бывают, но мне как прилетали все обновления HP через обновления Windows, так и продолжают прилетать. Но да, обновлятор от HR скопытился. Правда, сделал он это ещё в 22 году. В общем, тухлый такой инфоповод.
Не совсем понял, в чем новизна и инновационность, как это можно патентовать: у меня коллега в 2013 году с таким "двусторонним" ноутбуком ходил... говорил, что ему это нужно, чтобы клиентам на встречах было проще демонстрировать экран, не подсаживаясь рядом, не ища проектор и т.п.
Unihertz Atom L. Прямо сейчас 35 вкладок открыто, а ещё я на нем фотки в Raw редактирую в походных условиях. Недостатка оперативы не чувствую, а у меня её "всего лишь" 6 гигов .
Так преподносится, будто нет на свете Unihertz Atom L/XL. А они есть, уже несколько лет как, я вот с такого сейчас пишу. По компактности мой "старичок" новенький Танк уже сделает, т.к. не такой толстый.
Мегапиксили - ни о чем, в мой вот запихано 40, но получается так же мерзко, так и раньше было на 14и. Уверен, что и с фоткой будет не лучше.
К моему текущему Атому вопроса два:
Я за первые 2 года израсходовал ресурс кнопки включения - выключения, теперь она от случайного резкого движения может "нажаться" - и телефон уйдет в циклическую перезагрузку.
Экран. Через 2месяца использования начало проявляться призрачное изображение, особенно если было что-то белое. Меня в основном не парит, но порой фотки мешает шаманить.
Всё остальное у авторов получилось хорошо. На камеру не жалуюсь, потому что она ожидаемо плохая, просто не понимаю, зачем они пыжатся с мегапикселями. Вот если над этими двумя проблемами работали и в новом телефоне такого не случится - тогда стоило бы рассмотреть к покупке, даже несмотря на больший вес и размер. Хотяяя.... Тоже весьма спорно.
Моё личное впечатление: исследование скорее отражает портрет участника сообщества, а не портрет php-разработчика вообще. Как бы прикольно, но какие выводы из этой статистики делать - непонятно. Ну, молодцы, что провели.
Присоединюсь, вот совсем не хочется вас забивать ногами, но у меня в Москве точно такая же проблема с этим чертовым зумом и закрывающимися открытыми окнами, абсолютно на любой версии, на любом телефоне и во все времна, то есть за последние лет 5 минимум. А негодование людей, огребающих чудеса юзабилити на морозе, понятно вдвойне. Отправьте проектировщиков интерфейса в командировку в поля, в самую всратую погоду, пусть вернутся просветлёнными)))
Вот плюсую, статья реально выглядит как агитка в стиле "наших бьют, мы обделены и обижены, всем срочно на баррикады!" - и надёрганы выборочные факты, чтобы вызвать эмоциональную реакцию.
Дело вкуса. Я вот люблю фигурные скобки и ловерКэмэлКейз. А вот КамелКейз меня уже бесит пуще андер_скора. И отступ табами в 8 пробелов вызывает чувство, что олды точно где-то тут.
Но это, конечно, не должно быть критерием для оценки качества кода и языка в целом, везде свои традиции.
Угу, мой ноутбучный i5 8го поколения пошел варить кофе, ведь в душе он - кофеварка, а не проц для гейминга / разработки...
В плане расчёта столкновений не вижу разницы для тайловой карты и любой другой... Разве что у вас игровой процесс как в шахматах, объекты строго перемещаются по ячейкам, и сталкивать их непосредственно нет нужды.
Не совсем так. Размер карты сам по себе не имеет большого значения, важнее количество объектов на ней, которые приходится обсчитывать. Естественно, чтобы запихать больше объектов, нужны бОльшие карты, но это скорее следствие, а не причина.
У вас в примере на codepen я действительно увидел карту с небольшим числом объектов, с которыми современные процессоры (то есть наверное всё, что выпущено за последние 10 лет) могут справится простым перебором. А вот если объектов будет на порядки больше, то уже и самому топовому железу придётся не сладко. А уж тем более если расчёты идут на JS и в один поток (игнорируется наличие многаядер, работать будет только одно).
Можно провести простой эксперимент: сделайте такую карту, чтобы на ней было хотя бы 10 000 отдельных объектов, для которых считаются коллизии.
Ну в этом-то как раз ничего удивительного, я тоже зарабатываю сильно меньше разраба из финтеха или любого руководителя из корпорации. В собственной компании есть другие плюсы, если удалось правильно её "приготовить".
Другое дело, что хотелось бы услышать "раскрытие тайных знаний" не от какого-то среднестатистического хрена, а от человека, у которого действительно ПОЛУЧИЛОСЬ, вот прям с большой буквы. Так-то бизнесы открывают и держат на плаву много кто.
Сотня объектов - это уже много для системы, которая определяет столкновения перебором всего. У меня и на десктопе тормозило на меньшем числе. пришлось сначала написать QuadTree, но потом и его стало мало. Так что тут однозначно надо как-то резать пространство.
Даже если все ячейки пространства придётся держать активными - всё равно будет буст непосредственно при расчёте столкновения, т.к. выборка объектов будет ограничена. То, что я у себя "выключаю" ячейки, которые далеко от игрока или не в зоне видимости - это уже из области "сопутствующей оптимизации", и непосредственно к столкновениям отношения не имеет. Просто раз появилась возможность переиспользовать сделанные вычисления для чего-то ещё - то почему бы и нет.
Плюсую. А то ведь у меня тоже есть какая-то стратегия, идущая вразрез с принятой у технологических гигантов, и я могу о ней рассказать. И у оренбуржского разработчика Василия Помидорова есть. И у саратовского тимлида Николая Главнюкова.... Давайте срочно все выйдем и раскроем свои удивительные стратегии, а то ведь весь мир мучается в догадках и спать не может без этого знания...
Пока из интересного - только обманутые ожидания. Я-то думал, у него фамилия Борщ. А оказалось - просто банальный Борх, вот скукота-то....
Хммм, на днях запилил похожее для своего велосипеда, каждый объект в состоянии взаимодействия с другим взаимодействующим объектом отсылает ему список доступных экшенов на выбор, ломать, юзать, экипировать или что там ещё... Даже не подозревал, что это может быть реализовано так, что тормоза будут не при взаимодействии с объектом (у меня там, признаться, дофига абстракций, которые, уверен, дают ощутимый оверхэд), а просто при заходе на уровень =\
Да, почти так. Ну, я передаю ему не сам объект, а хитбокс объекта, для которого движок всё равно на каждом цикле будет расчитывать абсолютную позицию относительно мира, чтобы не делать эти вычисления повторно.
У SpatialGrid именно в том и суть, что мы можем отсекать большие группы объектов из работы над столкновениями, и не пробегаться по всем фрагментам игрового мира, а брать только активные. Поэтому тут однозначно HashMap, а не списки, т.к. предполагается, что ячеек очень-очень много и итерация по всем ним будет однозначно дольше, чем медленный доступ по ключу.
Хотя, я тут недавно разбирал, что можно в ряде случаев HashMap переписать на циклы, но в ходе профилирования у меня никогда не возникало случая, чтобы тормозил именно этот доступ по ключу. Уверен, на каком бы языке вы ни писали, это не станет узким местом. Уж меня Dart совсем не балует беспрецедентной скоростью работы, так что если бы в коде что-то тормозило - это точно сразу стало бы видно.
Но надо заметить, что всё зависит от игры: если у вас RPG, и в центре внимания персонаж, то можно замораживать или откладывать расчёты по фрагментам мира, которые находятся достаточно далеко от него. Если же это, скажем, RTS, то придётся одинаков скрупулёзно расчитывать события на всех участках карты - и тогда уже от итерации по всему списку никуда не деться.
Ну тут нет каких-то особых способов повлиять.
Можно либо полезть в исходники Skia и посмотреть, что же она делает с картинками под капотом, получить некое знание, и жить с ним дальше, т.к. повлиять на этот процесс всё равно не получится на уровне Dart. Мы просто сможем сказать "да, всё плохо" или "да забейте, всё хорошо".
Либо не разрабатывать свой продукт на инструментах, не дающих такого детального контроля, раз для продукта так критично даже то, в каком формате файлы улетают.
На уровне языка Dart есть только разделение на растризованную картинку и объект с записанными командами отрисовки. Всё. Не важно, грузим мы в Flutter jpg, png, bitmap или поток байтов со звуковой карты :-) В конечном итоге он пойдёт на видеокарту либо в одном либо в другом формате, и на то, что у этих форматов под капотом мы никак воздействовать не можем.