В этой линии сходу виднеется проблема: это же один сплошной bottleneck. Выход из строя любого важного элемента инфраструктуры может обрубить связь между двумя концами. И чем ближе к центру - тем больше потенциальный урон. Ладно электроэнергия, но жд, водопровод всякие должны быть как минимум продублированы на случай аварии - особенно жд (в 200 метров ширины не сильно много впихнешь). Ну и если параноить - на случай какого-нибудь карантина изолировать кусок "линии" будет непросто.
В детстве смотрел "битву роботов" - вот если бы статья была про постройку робота для подобного шоу - было бы интереснее. Там хоть и ограничения всякие, но роботы хотя бы боевые!
Если я правильно понял посыл, автор предлагает замести под ковер все неожиданные ситуации при работе с апи, мол, давайте апи будет заботиться о том, что кто-то может недостаточно тщательно подойти к тестированию (или невнимательно читать документацию) . Ну уж нет: явное лучше неявного. Если в системе нету принтеров, и в результате - о боже - вылетит исключение, то если его забыли обработать на этой системе - виноваты разработчики этой системы, а не апи (если, конечно, в документации апи явно указано, что такое-то исключение может быть брошено). Тем не менее, я соглашусь с тем, что изначально апи стоит проектировать так, чтобы оно не бросало исключений - в разных средах обработка исключений может быть тяжелой (привет с++) - лучше возвращать коды ошибок.
Так как по сути сроки решают за меня, я просто делаю задачи в обычном для меня темпе и в большинстве случаев успеваю. Нередко мне удается подвинуть сроки только лишь потому, что мои навыки все же ценят - просто кроме меня данную задачу мало кто сможет сделать так же быстро, ведь те, кто сможет - в таких конторах надолго не задеживаются.
Я работаю в Японии в бодишопе, и хотел бы рассказать, как на моем примере обстоят дела с разработкой в Японии.
Я как-то однажды об этом уже писал: в Японии разработка ПО, по сути, относится к сфере услуг, со всеми вытекающими. Помните знаменитые фразы "покупатель всегда прав" и прочее? Вот тут это возведено в абсолют, из-за азиатского менталитета "угодить покупателю заказчику любой ценой". И сроков это тоже касается. Твой менеджер спрашивает у тебя сроки, но они всегда упираются в "сделаем максимум за месяц", потому что заказчик имеет свое расписание, а дополнительных людей на проект выделять никто не будет. Также стоит держать в голове, что сторонними библиотеками почти наверняка пользоваться нельзя, ибо заказчик скорее всего не захочет возиться с лицензиями - так что никаких "кирпичиков", как пишут некоторые. За множество однотипных проектов собрал свои наработки в библиотеку? Тебе не разрешат ее использовать в следующем проекте, потому что это лишняя dll, хотя никаких причин для этого нет - разве что "заказчик может не захотеть", о чем заказчика менеджер на самом деле спрашивать не станет. Заказчик захотел 3д в приложении? Пиши на opengl с нуля. Ну как с нуля, приходится чуть ли не умолять менеджера, чтобы разрешил использовать glfw и glew (и то, представьте, когда вы сидите на митинге с заказчиком и менеджер заискивающим тоном сначала неловко спрашивает об этих 2 библиотеках, и тут же оговаривается, что в принципе можно обойтись и без любой из них, если заказчику "неуютно"). Когда тебя спрашивают почему ты хочешь их использовать - отвечаешь резонное "потому что имею опыт работы, в 3д-области это важно" - и тебе менеджер делает замечание, что так заказчику говорить нельзя, мол, я навязываю тем свой выбор... В общем, нельзя беспокоить заказчика, а точнее - как либо потенциально обременять. Чтобы вы понимали специфику - в Японии работники сферы услуг вечно кланяются и благодарят покупателей-посетителей за любой чих, и даже извиняются за то, что просто оказались на пути вашего взгляда до нужной вам полки с товаром. И вот подобное поведение проецируется и на разработку. Даже если это поведение вредит результату. Еще раз уточню - я не говорю за всех, но когда на корпоративах спрашиваешь у местного начальства, они утверждают, мол, это нормальный подход в японских компаниях.
Использую домашний NAS-диск, в который встроен transmission. Таким образом, пока комп выключен/спит, железка сама качает в себя. Покупал ради бэкапов, встроенный в железку торрент-клиент оказался приятным бонусом.
Вместо интерфейса я бы хотел обратить внимание на другое - цветовую гамму. Я никогда не понимал, как дизайнерам варкрафта - и его последователям (ВоВ, дота и прочие) пришло в голову взять и запихать всю цветовую палитру радуги одновременно на экран - когда даже трава на фоне своей яркостью соревнуется за внимание игрока. В той же доте - когда начинается драка, непривыкшему игроку будет трудно разобрать, где свои, где чужие, где среди них - мой персонаж, а вообще где курсор... И только спустя много сеансов выжигания сетчатки, начинаешь адаптироваться. Боковым зрением трудно разглядеть происходящее на миникарте, ибо даже миникарта начинает сливаться со всем цветовым разнообразием. Как хороший на мой взгляд пример - было сделано в WoT танках, где события на миникарте сразу замечались одним лишь боковым зрением. Ну или та же Lineage 2, где многим все может показаться тусклым, но лично я предпочитаю тот вариант, где самая большая яркость на экране "зарезервирована" только теми элементами, которые нужно будет найти сразу боковым зрением и при этом не будет тонуть в феерверке спецэффектов или, не дай бог, фона.
В Японии ездил на таком - особенно классно, когда такое "метро" выходит на поверхность и наоборот - едет по мосту над землей: обзор из лобового стекла просто шикарен!
Для повседневных нужд использую встроенный в Visual Studio гит. Да, в нем многого нет, но мне нравится его киллер-фича - поддержка синтаксиса в диффе (а с решарпером можно смотреть локальное изменение, не отрываясь от строчки в исходнике). Для всего остального - гит через консоль.
Тогда можно пойти ещё дальше и написать "компилятор", который распознает main(), но не распознает его содержимое - тогда наверняка можно ужать размер до феноменального минимума
Видел одно полезное применение таким видео: на стриме, где музыка/видео за донат, когда случается наплыв из донатов всяких гачи/русского рэпа и начинают вянуть уши, иногда находится донатер-спаситель и ставит вот такой вот видос с тишиной (даже пусть 5 минут тишины только - уже хорошо).
В мелькающей статье вроде бы было написано про банки по большей части. У нас в обычной софтверной фирме стоят системники без флоппи-дисководов, но еще с DVD-дисководами (часть лицензионного софта до сих пор выдают на дисках).
Хах, кстати говоря, в 5 цивилизации при игре с игроками попытка улететь на другой глобус обычно сопровождается глобальной войной со всеми, ожиданием ядерных бомбардировок, страна в огне, все разграблено, распродаются всякие научные лаборатории да школы, частично распродается дорогая армия, а столицу окружают простые рабочие и остатки войск, чтобы своими телами прикрывать попытку правительства успешно свалить 😉
Тоже заводил себе правило: играть только с несколькими дополнениями. Помимо возрастающей сложности и увеличения длительности игры, при росте числа карточек баланс сильно смещается в пользу захвата полей. Пробовал играть двойным набором - вот там это было сильно заметно
Недавно мне как раз пришлось искать и удалять все неиспользованные исходники из проекта (притом с чётким осознанием того, что линкер всё равно всё неиспользуемое в бинарник не положит, просто ради красоты отчёта статического анализатора на стороне заказчика) и могу сказать, что чтобы удалить программно исходник из проекта IAR, нужно удалить его запись сразу из 5 проектных файлов - иначе весьма высока вероятность того, что он волшебным образом вернётся обратно при последующем открытии IDE... И причины использования ровно те же - заказчик заплатил за него, а значит все будут страдать. Особенно увлекательно выглядит процесс работы в команде, когда заказчик расщедрился аж на целую ОДНУ сетевую лицензию на команду - то есть если в команде кто-то запустил в IAR сборку - все остальные не смогут пользоваться компилятором на своих машинах в ближайшие полчаса...
Я считаю, делать гц "универсальным аллокатором" для всех new смысла нет (тогда лучше выбрать другой язык), но имеет смысл создавать определенные высокоуровневые категории объектов через гц (например, игровые сущности). При этом созданные через гц-аллокатор объекты не должны торчать наружу указателями вообще - а иметь свой умный указатель, позволяющий отгородить внешнюю логику от доступа по висячей ссылке. В c++/cli похожая схема, где можно создавать объекты как через new, так и через gcnew.
В своем проекте я решал эту проблему кастомным полуумным указателем: уничтожение вызывается только вручную вызовом метода destroy на самом указателе, но все копии этого указателя впоследствии разыменовываются в nullptr (избегаем висячих ссылок). Ну и, собственно, как и вызов delete на nullptr безопасен, так и destroy внутри другого destroy не будет делать ничего. А вообще, желательно избегать использование деструктора и по возможности создавать объекты через фабричный метод и задавать там функцию удаления. Таким образом решается проблема возможного вызова виртуальных методов в конструкторе и деструкторе.
В этой линии сходу виднеется проблема: это же один сплошной bottleneck. Выход из строя любого важного элемента инфраструктуры может обрубить связь между двумя концами. И чем ближе к центру - тем больше потенциальный урон. Ладно электроэнергия, но жд, водопровод всякие должны быть как минимум продублированы на случай аварии - особенно жд (в 200 метров ширины не сильно много впихнешь). Ну и если параноить - на случай какого-нибудь карантина изолировать кусок "линии" будет непросто.
В детстве смотрел "битву роботов" - вот если бы статья была про постройку робота для подобного шоу - было бы интереснее. Там хоть и ограничения всякие, но роботы хотя бы боевые!
Если я правильно понял посыл, автор предлагает замести под ковер все неожиданные ситуации при работе с апи, мол, давайте апи будет заботиться о том, что кто-то может недостаточно тщательно подойти к тестированию (или невнимательно читать документацию) . Ну уж нет: явное лучше неявного. Если в системе нету принтеров, и в результате - о боже - вылетит исключение, то если его забыли обработать на этой системе - виноваты разработчики этой системы, а не апи (если, конечно, в документации апи явно указано, что такое-то исключение может быть брошено). Тем не менее, я соглашусь с тем, что изначально апи стоит проектировать так, чтобы оно не бросало исключений - в разных средах обработка исключений может быть тяжелой (привет с++) - лучше возвращать коды ошибок.
Так как по сути сроки решают за меня, я просто делаю задачи в обычном для меня темпе и в большинстве случаев успеваю. Нередко мне удается подвинуть сроки только лишь потому, что мои навыки все же ценят - просто кроме меня данную задачу мало кто сможет сделать так же быстро, ведь те, кто сможет - в таких конторах надолго не задеживаются.
Я работаю в Японии в бодишопе, и хотел бы рассказать, как на моем примере обстоят дела с разработкой в Японии.
Я как-то однажды об этом уже писал: в Японии разработка ПО, по сути, относится к сфере услуг, со всеми вытекающими. Помните знаменитые фразы "покупатель всегда прав" и прочее? Вот тут это возведено в абсолют, из-за азиатского менталитета "угодить
покупателюзаказчику любой ценой". И сроков это тоже касается. Твой менеджер спрашивает у тебя сроки, но они всегда упираются в "сделаем максимум за месяц", потому что заказчик имеет свое расписание, а дополнительных людей на проект выделять никто не будет. Также стоит держать в голове, что сторонними библиотеками почти наверняка пользоваться нельзя, ибо заказчик скорее всего не захочет возиться с лицензиями - так что никаких "кирпичиков", как пишут некоторые. За множество однотипных проектов собрал свои наработки в библиотеку? Тебе не разрешат ее использовать в следующем проекте, потому что это лишняя dll, хотя никаких причин для этого нет - разве что "заказчик может не захотеть", о чем заказчика менеджер на самом деле спрашивать не станет. Заказчик захотел 3д в приложении? Пиши на opengl с нуля. Ну как с нуля, приходится чуть ли не умолять менеджера, чтобы разрешил использовать glfw и glew (и то, представьте, когда вы сидите на митинге с заказчиком и менеджер заискивающим тоном сначала неловко спрашивает об этих 2 библиотеках, и тут же оговаривается, что в принципе можно обойтись и без любой из них, если заказчику "неуютно"). Когда тебя спрашивают почему ты хочешь их использовать - отвечаешь резонное "потому что имею опыт работы, в 3д-области это важно" - и тебе менеджер делает замечание, что так заказчику говорить нельзя, мол, я навязываю тем свой выбор... В общем, нельзя беспокоить заказчика, а точнее - как либо потенциально обременять. Чтобы вы понимали специфику - в Японии работники сферы услуг вечно кланяются и благодарят покупателей-посетителей за любой чих, и даже извиняются за то, что просто оказались на пути вашего взгляда до нужной вам полки с товаром. И вот подобное поведение проецируется и на разработку. Даже если это поведение вредит результату. Еще раз уточню - я не говорю за всех, но когда на корпоративах спрашиваешь у местного начальства, они утверждают, мол, это нормальный подход в японских компаниях.Живя в Японии, меня больше волнует физическая целостность сего девайса, на случай землетрясения (у всех своя паранойя).
Он живет в локальной домашней сети, для работы торрент-клиента пробрасывается порт - и все делов.
Использую домашний NAS-диск, в который встроен transmission. Таким образом, пока комп выключен/спит, железка сама качает в себя. Покупал ради бэкапов, встроенный в железку торрент-клиент оказался приятным бонусом.
Вместо интерфейса я бы хотел обратить внимание на другое - цветовую гамму. Я никогда не понимал, как дизайнерам варкрафта - и его последователям (ВоВ, дота и прочие) пришло в голову взять и запихать всю цветовую палитру радуги одновременно на экран - когда даже трава на фоне своей яркостью соревнуется за внимание игрока. В той же доте - когда начинается драка, непривыкшему игроку будет трудно разобрать, где свои, где чужие, где среди них - мой персонаж, а вообще где курсор... И только спустя много сеансов выжигания сетчатки, начинаешь адаптироваться. Боковым зрением трудно разглядеть происходящее на миникарте, ибо даже миникарта начинает сливаться со всем цветовым разнообразием. Как хороший на мой взгляд пример - было сделано в WoT танках, где события на миникарте сразу замечались одним лишь боковым зрением. Ну или та же Lineage 2, где многим все может показаться тусклым, но лично я предпочитаю тот вариант, где самая большая яркость на экране "зарезервирована" только теми элементами, которые нужно будет найти сразу боковым зрением и при этом не будет тонуть в феерверке спецэффектов или, не дай бог, фона.
Если с титаном случился "чпок", то с титаником - "хрясь". И у обоих не выдержал корпус в столкновении с суровой физикой
В Японии ездил на таком - особенно классно, когда такое "метро" выходит на поверхность и наоборот - едет по мосту над землей: обзор из лобового стекла просто шикарен!
Для повседневных нужд использую встроенный в Visual Studio гит. Да, в нем многого нет, но мне нравится его киллер-фича - поддержка синтаксиса в диффе (а с решарпером можно смотреть локальное изменение, не отрываясь от строчки в исходнике). Для всего остального - гит через консоль.
Тогда можно пойти ещё дальше и написать "компилятор", который распознает main(), но не распознает его содержимое - тогда наверняка можно ужать размер до феноменального минимума
Видел одно полезное применение таким видео: на стриме, где музыка/видео за донат, когда случается наплыв из донатов всяких гачи/русского рэпа и начинают вянуть уши, иногда находится донатер-спаситель и ставит вот такой вот видос с тишиной (даже пусть 5 минут тишины только - уже хорошо).
В мелькающей статье вроде бы было написано про банки по большей части. У нас в обычной софтверной фирме стоят системники без флоппи-дисководов, но еще с DVD-дисководами (часть лицензионного софта до сих пор выдают на дисках).
Хах, кстати говоря, в 5 цивилизации при игре с игроками попытка улететь на другой глобус обычно сопровождается глобальной войной со всеми, ожиданием ядерных бомбардировок, страна в огне, все разграблено, распродаются всякие научные лаборатории да школы, частично распродается дорогая армия, а столицу окружают простые рабочие и остатки войск, чтобы своими телами прикрывать попытку правительства успешно свалить 😉
Тоже заводил себе правило: играть только с несколькими дополнениями. Помимо возрастающей сложности и увеличения длительности игры, при росте числа карточек баланс сильно смещается в пользу захвата полей. Пробовал играть двойным набором - вот там это было сильно заметно
Недавно мне как раз пришлось искать и удалять все неиспользованные исходники из проекта (притом с чётким осознанием того, что линкер всё равно всё неиспользуемое в бинарник не положит, просто ради красоты отчёта статического анализатора на стороне заказчика) и могу сказать, что чтобы удалить программно исходник из проекта IAR, нужно удалить его запись сразу из 5 проектных файлов - иначе весьма высока вероятность того, что он волшебным образом вернётся обратно при последующем открытии IDE... И причины использования ровно те же - заказчик заплатил за него, а значит все будут страдать. Особенно увлекательно выглядит процесс работы в команде, когда заказчик расщедрился аж на целую ОДНУ сетевую лицензию на команду - то есть если в команде кто-то запустил в IAR сборку - все остальные не смогут пользоваться компилятором на своих машинах в ближайшие полчаса...
Я считаю, делать гц "универсальным аллокатором" для всех new смысла нет (тогда лучше выбрать другой язык), но имеет смысл создавать определенные высокоуровневые категории объектов через гц (например, игровые сущности). При этом созданные через гц-аллокатор объекты не должны торчать наружу указателями вообще - а иметь свой умный указатель, позволяющий отгородить внешнюю логику от доступа по висячей ссылке. В c++/cli похожая схема, где можно создавать объекты как через new, так и через gcnew.
В своем проекте я решал эту проблему кастомным полуумным указателем: уничтожение вызывается только вручную вызовом метода destroy на самом указателе, но все копии этого указателя впоследствии разыменовываются в nullptr (избегаем висячих ссылок). Ну и, собственно, как и вызов delete на nullptr безопасен, так и destroy внутри другого destroy не будет делать ничего. А вообще, желательно избегать использование деструктора и по возможности создавать объекты через фабричный метод и задавать там функцию удаления. Таким образом решается проблема возможного вызова виртуальных методов в конструкторе и деструкторе.