Вот мне интересно откуда автор знает какова ситуация в бигтех компаниях?
Наличие GC никого не останавливает использовать Kotlin или Java.
У Go есть своя конкретная ниша и осел там довольно уверенно. DevOps тулы не система реального времени. И только самый ярый фанат будет использовать его для написания игр или HFT
Я конечно не особый эксперт в Nginx, но X-Real-Ip это же вроде заголовок HTTP. И причем здесь TCP/UDP? Видимо что бы получить сертификат о прохождении курса в Otus, нужно написать статью в блог компании.
Хех, мне кажется что это статья ради статьи. Ведь в озоновской конвенции по микросервисам вроде бы было написано что все сервисы должны общаться по gRPC
Мне кажется что есть более простой вариант для "Распространение protobuf модели". Каждый сервис хранит модель у себя. Клиенты ее импортируют (тут конечно зависит от ЯП, ка реализовать импорт). И за использовать тулу чтобы не ломать бек совместимость proto. Монорепа в крупных компаниях делается не для этого и никто не хранит там все протофоайлы в одной директории.
Мне кажется что это нарушает большое количество лучших практик про то что тестовое окружение должно быть приближенно к проду. Это примерно тоже самое что если бы в породе вы использовали MsSql а локально postgres
Основаная разница между задачами про аптеки и задач про новый сервис - это контекст. В задаче про аптеки его нет вообще. А в задаче про сервис - он очень большой, вы знаете что за нагрузка, какие есть подводные камни и тп. Если формулировать задачу про сервис в таком же стиле то она должна звучать так "Сколько гигабайт нужно добавить в сервис что бы он не падал?"
Я не встречал высокопроизводительного кода, который был бы лёгок в чтении, тестировании и модификации
Что означает высоко производительный? Этот термин примерно такой же как и highload - многие употребляют но без особого понимания. В современном мире намного важнее что бы система была горизонтально масштабируемая, а это достигается задолго до написания кода. А для бизнес заказчиков (ведь вы не пилите сервис просто что бы пилить сервис) важна скорость разработки фич. Большинство из этих трюков не нужны и даже вредны (если они конечно не находятся в каких то кор библиотеках). Мне кажется кажется что типовой паттерн использования интерфейсов - абстракция от внешних зависимостей (БД, ФС и тп). И то что вы выиграете 1нс от отказа от использовая интерфейсов глобальную картину не поменяет, но сильно усложнит жизнь в будущем.
А чем эта статья отличается от других статьей на Хабре про merge tree в clickhouse ? Я когда открывал статью думал "Неужели очередная статья про merge tree?". Так и оказалось :(
В пресловутом IELTS есть разговорная часть. Где за 1 минуту нужно подготовить 2ух минутный спич на какую то тему (например загрязнение мирового океана). Я даже на русском не всегда могу сделать. IELTS как и любой тест проверяет твою подготовку к прохождению теста, и не всегда актуальные знания/умения.
Не понимаю почему автору ставят минусы. Сам работаю в пресловутом FAANG и полностью поддерживаю. Во первых нейтив спикеров тут не очень много. Большая часть коммуникации ведётся онлайн. И если что то не понятно то не зазорно попросить коллегу повторить мысль. Нейтив спикеры довольно довольно редко используют идиомы так что с этим проблем тоже нет. Но вот что действительно важно - умение писать - но тут больше про правильность изложения своих мыслей. И опять же есть всякие чат боты которые в этом помогают
Большие и сложные проекты: Требуется более частый и систематический рефакторинг
Вообще не согласен с этим поинтом. Имхо частота рефакторинга зависит от того как часто в код вносятся изменения (ведь при реализации изначального функционала оно и так должно реализовано нормально) и не сколько изначальная реализация хорошо и расширяемо написано (a.k.a. на сколько изначальный разработчик сделал решение гибким)
Интересно, а почему выбор пал на питон, а не на одну из С++ библиотек для работы с большими числами. Хотя бы тот же самый boost. https://www.boost.org/doc/libs/1_79_0/libs/multiprecision/doc/html/index.html
Согласен, фаззинг помогает находить ошибки в работе с сырыми данными. Но тейк о том что он помогает сократить время на фикс багов мне не понятен. Возьмём ваш пример с ограничением кол-ва эмоджи в тексте, что именно будет тестировать фаззер? Как поменяется тест если ограничение нужно поменять с 3 до 4?
Вот мне интересно откуда автор знает какова ситуация в бигтех компаниях?
Наличие GC никого не останавливает использовать Kotlin или Java.
У Go есть своя конкретная ниша и осел там довольно уверенно. DevOps тулы не система реального времени. И только самый ярый фанат будет использовать его для написания игр или HFT
Я конечно не особый эксперт в Nginx, но X-Real-Ip это же вроде заголовок HTTP. И причем здесь TCP/UDP? Видимо что бы получить сертификат о прохождении курса в Otus, нужно написать статью в блог компании.
Хех, мне кажется что это статья ради статьи. Ведь в озоновской конвенции по микросервисам вроде бы было написано что все сервисы должны общаться по gRPC
Если честно, то ощущение что у автора смешалось все в кучу, и он сам не особо понимает о чем пишет.
В чем заключается децентрализация? Что такое высокая нагрузка? Выглядит как преждевременная оптимизация сайта личного блога.
Мне кажется что есть более простой вариант для "Распространение protobuf модели". Каждый сервис хранит модель у себя. Клиенты ее импортируют (тут конечно зависит от ЯП, ка реализовать импорт). И за использовать тулу чтобы не ломать бек совместимость proto. Монорепа в крупных компаниях делается не для этого и никто не хранит там все протофоайлы в одной директории.
Выглядит как чисто рекламный пост.
Мне кажется что это нарушает большое количество лучших практик про то что тестовое окружение должно быть приближенно к проду. Это примерно тоже самое что если бы в породе вы использовали MsSql а локально postgres
Основаная разница между задачами про аптеки и задач про новый сервис - это контекст. В задаче про аптеки его нет вообще. А в задаче про сервис - он очень большой, вы знаете что за нагрузка, какие есть подводные камни и тп. Если формулировать задачу про сервис в таком же стиле то она должна звучать так "Сколько гигабайт нужно добавить в сервис что бы он не падал?"
Так а где сравнение производительности? Только какое то теоретическое сравнение без цифр.
Что означает высоко производительный? Этот термин примерно такой же как и highload - многие употребляют но без особого понимания. В современном мире намного важнее что бы система была горизонтально масштабируемая, а это достигается задолго до написания кода. А для бизнес заказчиков (ведь вы не пилите сервис просто что бы пилить сервис) важна скорость разработки фич. Большинство из этих трюков не нужны и даже вредны (если они конечно не находятся в каких то кор библиотеках). Мне кажется кажется что типовой паттерн использования интерфейсов - абстракция от внешних зависимостей (БД, ФС и тп). И то что вы выиграете 1нс от отказа от использовая интерфейсов глобальную картину не поменяет, но сильно усложнит жизнь в будущем.
А чем эта статья отличается от других статьей на Хабре про merge tree в clickhouse ? Я когда открывал статью думал "Неужели очередная статья про merge tree?". Так и оказалось :(
В пресловутом IELTS есть разговорная часть. Где за 1 минуту нужно подготовить 2ух минутный спич на какую то тему (например загрязнение мирового океана). Я даже на русском не всегда могу сделать. IELTS как и любой тест проверяет твою подготовку к прохождению теста, и не всегда актуальные знания/умения.
Не понимаю почему автору ставят минусы. Сам работаю в пресловутом FAANG и полностью поддерживаю. Во первых нейтив спикеров тут не очень много. Большая часть коммуникации ведётся онлайн. И если что то не понятно то не зазорно попросить коллегу повторить мысль. Нейтив спикеры довольно довольно редко используют идиомы так что с этим проблем тоже нет. Но вот что действительно важно - умение писать - но тут больше про правильность изложения своих мыслей. И опять же есть всякие чат боты которые в этом помогают
Следующий шаг хранить шифрованные файлы на гитхабе?
Интересно, а почему kloop.org считается общественно важным? Больше походит на какую-то страницу для проверки работы WordPress
Из текста не совсем понятно, зачем тут идёт речь о pyroscope и parca. Это альтернативные решения которые не подошли? Или у вас все 3 решения работают.
Вообще не согласен с этим поинтом. Имхо частота рефакторинга зависит от того как часто в код вносятся изменения (ведь при реализации изначального функционала оно и так должно реализовано нормально) и не сколько изначальная реализация хорошо и расширяемо написано (a.k.a. на сколько изначальный разработчик сделал решение гибким)
Но эта возможность есть и в стандартном плеере Ютуба, если не жлобить 200р в месяц
Интересно, а почему выбор пал на питон, а не на одну из С++ библиотек для работы с большими числами. Хотя бы тот же самый boost. https://www.boost.org/doc/libs/1_79_0/libs/multiprecision/doc/html/index.html
Согласен, фаззинг помогает находить ошибки в работе с сырыми данными. Но тейк о том что он помогает сократить время на фикс багов мне не понятен. Возьмём ваш пример с ограничением кол-ва эмоджи в тексте, что именно будет тестировать фаззер? Как поменяется тест если ограничение нужно поменять с 3 до 4?