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