Эту картинку не стоит рассматривать слишком буквально. Или просто я её воспринял по-другому. Руководитель должен своим примером вдохновлять свою команду и он не должен бояться засучить рукава и помочь команде, когда это требуется.
В ОСЗН заведующая иногда осуществляла прием людей по оформлению льгот/субсидий, когда мы все были в мыле, а в коридоре толпилась куча народа. Мы это видели и впахивались по-полной.
Там же, где в состоянии дедлайна руководитель только пинговал меня каждый час и продолжал заниматься своими делами, особого рвения я не чувствовал.
Возможно я не отразил в статье, что всё мною написанное лишь мой субъективный взгляд и мои принципы, которыми я руководствуюсь. Это то, чему я научился и чему я следую - не стоит пытаться натянуть эти правила на свой опыт.
Всё верно, до момента, когда размер передаваемых данных увеличивается критично (постараюсь в сл части показать этот момент, если получится реализовать это в программном стенде). Если обмениваться маленькими JSON структурами, то статью можно не читать. Если структуры увеличиваются, то скорость JSON сериализации/десериализации падает ощутимо.
Вторая часть уже почти готова. Не стал делать long-long-story. Тем более теперь появились новые мысли, что нужно бы добавить/доправить, чтобы цифры были интереснее.
Это второе решение после JSON, которое не требует отдельного изучения для вновь пришедших в команду. Это серьёзное преимущество для коммерческой разработки.
Всё верно, сравнение не совсем "нормально" с математической точки зрения. Но мы живём не в идеальном мире: любые решения будут иметь свои наборы свойств и особенностей, которые нельзя будет привести к общему знаменателю. Статья разбирает решения не только с технической точки зрения, но и со стороны эксплуатации/разработки ("административная" стороны медали).
Можно и реализовать своё решение со схемами, дебагом и сусликами, которое будет соответствовать всем требованиям. Но такое решение будет технико-экономически неконкурентоспособно, так как на него нужно ещё до начала эксплуатации затратит много человекочасов и не факт, что результат будет лучше.
Внутри команды рассматривали flatbuffers. Он действительно самый быстрый, как пишет ErgoZru, но и достаточно сыроват/нестабилен для комбинации flatbuffers + gRPC. Поэтому пока следим за развитием.
Вероятно, Вы в чем-то правы. Я же написал, что я учусь. Через пару лет я перечитаю эту статью и оставлю коммент, в котором напишу, что изменилось :)
Эту картинку не стоит рассматривать слишком буквально. Или просто я её воспринял по-другому. Руководитель должен своим примером вдохновлять свою команду и он не должен бояться засучить рукава и помочь команде, когда это требуется.
В ОСЗН заведующая иногда осуществляла прием людей по оформлению льгот/субсидий, когда мы все были в мыле, а в коридоре толпилась куча народа. Мы это видели и впахивались по-полной.
Там же, где в состоянии дедлайна руководитель только пинговал меня каждый час и продолжал заниматься своими делами, особого рвения я не чувствовал.
Возможно я не отразил в статье, что всё мною написанное лишь мой субъективный взгляд и мои принципы, которыми я руководствуюсь. Это то, чему я научился и чему я следую - не стоит пытаться натянуть эти правила на свой опыт.
Я стараюсь делать так, чтобы все занимались той работой, которую необходимо выполнить и то время, когда это необходимо.
Это тот инженер, который должен был везти песок с третьей базы на четвертую, но все перепутал?
Если нужно нативное решение, то можно использовать https://pkg.go.dev/encoding/gob https://pkg.go.dev/net/rpc Для своих pet проектов отлично работает.
Всё верно, до момента, когда размер передаваемых данных увеличивается критично (постараюсь в сл части показать этот момент, если получится реализовать это в программном стенде). Если обмениваться маленькими JSON структурами, то статью можно не читать. Если структуры увеличиваются, то скорость JSON сериализации/десериализации падает ощутимо.
Да, хорошо подмечено: proto - это schema-first решение, msgpack и gob - это всё таки code-first решение.
Как писал уже выше, вторая часть будет чуть позже.
Спасибо про аллокации, я их не сравнивал, добавлю в следующей части.
Вторая часть уже почти готова. Не стал делать long-long-story. Тем более теперь появились новые мысли, что нужно бы добавить/доправить, чтобы цифры были интереснее.
Это второе решение после JSON, которое не требует отдельного изучения для вновь пришедших в команду. Это серьёзное преимущество для коммерческой разработки.
Всё верно, сравнение не совсем "нормально" с математической точки зрения. Но мы живём не в идеальном мире: любые решения будут иметь свои наборы свойств и особенностей, которые нельзя будет привести к общему знаменателю.
Статья разбирает решения не только с технической точки зрения, но и со стороны эксплуатации/разработки ("административная" стороны медали).
Можно и реализовать своё решение со схемами, дебагом и сусликами, которое будет соответствовать всем требованиям. Но такое решение будет технико-экономически неконкурентоспособно, так как на него нужно ещё до начала эксплуатации затратит много человекочасов и не факт, что результат будет лучше.
Внутри команды рассматривали flatbuffers. Он действительно самый быстрый, как пишет ErgoZru, но и достаточно сыроват/нестабилен для комбинации flatbuffers + gRPC. Поэтому пока следим за развитием.
Для javascript решения пока нет. IMHO наличие такого решения, возможно, могло увеличить интерес к этому формату