Здравствуйте, kaa.python, Вы писали:
KP>Ну может не по стилю, но по тому как надо писать таки есть.
https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines
...
NL.10: Prefer underscore_style names
...
must follow an established style for consistency
Здравствуйте, Ватакуси, Вы писали:
В>Сложно сказать наверняка, ибо мне ответ дали на английском и писал человек его не очень хорошо знающий. Но похоже, им нужно было всё в контейнеры завернуть, устроить устойчивый кластер, подумать о петафлопах и самое главное в readme написать как я решал задачу. В>Всё это совершенно не оговаривалось заранее, более того было сказано "тебе выбирать решение".
Согласен, странно требовать от тестового задания решения "production ready" уровня. Тем более если это явно не сказано.
Да и сам термин довольно размыт. У меня бы это означало что нужно логирование нормально сделать, health-check-и добавить, мониторинг, всякие corner cases проверить и т.п., а нужны ли там контейнеры, HA и пр. это уже надо по заданию смотреть.
В>Это вообще по Яве было собеседование, но спрашивали про питон :D
Понятно, умные указатели сбили меня с толку
Мы были здесь. Но пора идти дальше. (с) Дуглас Коупленд, Рабы "Микрософт"
S>https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines
S>...
S>NL.10: Prefer underscore_style names
S>...
S>must follow an established style for consistency
S>
Вот это интереснее:
NL.8: Use a consistent naming style
Rationale: Consistence in naming and naming style increases readability.
Note
There are many styles and when you use multiple libraries, you can’t follow all their different conventions. Choose a “house style”, but leave “imported” libraries with their original style.
т.е. получается я прав и с соглашениями по именованию в С++ бардак т.е. какого-то единого или доминируещего соглашения нет, поэтому придумывайте своё соглашение и используйте его в своём коде. Грубо говоря, получается: сколько компаний столько и соглашений. Как-то грустно это выглядит.
Мы были здесь. Но пора идти дальше. (с) Дуглас Коупленд, Рабы "Микрософт"
Здравствуйте, smeeld, Вы писали:
S>Для подростающего молодняка, продакшон код означает упаковаанность в докер, ибо так в очередном новомодном букваре от очередного болтуна написано.
Нет, что вы. Контейнеры, Docker, k8s и пр. это всё для таких старперов как я Подрастающее поколение сейчас интересуется serverless архитектурой, хотя вроде и этот хайп уже на исходе
Мы были здесь. Но пора идти дальше. (с) Дуглас Коупленд, Рабы "Микрософт"
Здравствуйте, Skorodum, Вы писали:
S>Если тестовое задание большое или явно оговоренно использование гита, то вполне логично желание увидеть историю разработки и умение пользоваться гитом.
Еще логичнее озвучить заранее желание видеть коммит после каждой новой строчки. У людей в конце-концов разные стили работ бывают. Гит же использовали вроде.
UUA>>Короче эти уроды если хотят отказать всегда найдут тысячу и одну причину. S>Отказали -> "уроды"?
Если отказ только по этой причине, то это действительно, странные люди. Но скорее он им просто не понравился, прямо же так сказать обычно нельзя, вот и придумывают в таких случаях разные причины.
UUA>>Один раз мне вообще заявили, что отказывают потому, что у меня в коде тестового задания было разное кол-во пробелов-строк между методами — где-то 2, а где-то аж 3! S>Вряд ли именно поэтому, но "не аккуратное форматирование" — еще один штрих
S>З.Ы. IMHO, больше одной пустой строки не нужно никогда.
Здравствуйте, Michael7, Вы писали:
M>Почему? Чисто для облегчения чтения.
Смотря где эта пустая строка. Если так предусмотрено стандартом или общепринятыми правилами, то ладно. Но вот когда пустая строка встретилась внутри метода/процедуры/функции, это прямо беда. Это просто расширяет границы экрана, и проплачено производителями мониторов. Когда читаешь такой код "через столетия", всегда хочется спросить у автора, что он имел ввиду. Ну потому что, если он отделил одну часть кода от другой, то ему следовало написать комментарий, чем эти части отличаются. Ну или поделиться откатами с теми, кто такой код читает после него.
Здравствуйте, Ватакуси, Вы писали:
В>Вот мне на вид поставили, что я не написал production ready code. В>Т.е., всё работает, всё правильно, но не production ready.
В>А в другом месте им camelCase не понравился. Это говорит противоречит стандарту :D
Если это всё на собеседовании и в тестовом задании — так радуйся, что не попал туда.
Здравствуйте, Michael7, Вы писали:
M>Еще логичнее озвучить заранее желание видеть коммит после каждой новой строчки.
Нет. Дело не в размере коммита, а в минимальном логичном и целостном изменении. Коммит может быть и 1000 строк, а может быть и один символ. Собственно, эта дискуссия хорошо демонстрирует проблему.
M>У людей в конце-концов разные стили работ бывают.
Во-во и некоторые стили в команду лучше не брать, т.к. переучивать "сеньёров" на нормальное пользование системой контролей версий дело очень неблагодарное
M>Если отказ только по этой причине, то это действительно, странные люди.
В общем случае каким бы хорошим кандидат не был, всегда есть вероятность, что был кто-то БОЛЕЕ ПОДХОДЯЩИЙ конкретно им. Отказ — это совершенно нормально, детальный feedback — вообще круто.
M>Но скорее он им просто не понравился, прямо же так сказать обычно нельзя, вот и придумывают в таких случаях разные причины.
Да это все домыслы. Надо не искать виртуальные причины для обиды, а понять, почему кто-то оказался более подходящим.
S>>З.Ы. IMHO, больше одной пустой строки не нужно никогда. M>Почему? Чисто для облегчения чтения.
Чтение это никак не облегачает, а вот непоследовательность в использовании пустых строк будет лишним раздражителем.
Сложно формализировать когда использовать одну пустую строку, а когда больше. Поэтому всем проще если всегда только одна пустая строка.
Здравствуйте, smeeld, Вы писали:
S>Для подростающего молодняка, продакшон код означает упаковаанность в докер, ибо так в очередном новомодном букваре от очередного болтуна написано.
Если к проекту идет контейнер который позволяет его намного проще собрать и запустить, то это однозначно большой плюс. Разве нет?
Здравствуйте, Closer, Вы писали:
C>т.е. получается я прав и с соглашениями по именованию в С++ бардак т.е. какого-то единого или доминируещего соглашения нет, поэтому придумывайте своё соглашение и используйте его в своём коде. Грубо говоря, получается: сколько компаний столько и соглашений. Как-то грустно это выглядит.
Да нормально. Если два основных формализованных и логичных стиля: Qt — CamelCase и stl/boost — snake_case. Есть извращенцы которые их мешают, есть извращены которые любят подчеркивания в начале или в конце, код превращаеся в азбуку Морзе: variable_._another_variable
Здравствуйте, Skorodum, Вы писали:
S>Если к проекту идет контейнер который позволяет его намного проще собрать и запустить, то это однозначно большой плюс. Разве нет?
Нет. Софт должен распростарняться в пакетах под конкретную ОС. Деплоить софт вместе с образами системного окружения ОС-это эра засилья безмозглых девляпсов. Докер-это прежде всего система контейнерной виртуализации и изоляции приложений. Самая худшая из всех, которые сть (solaris zone, freebsd jail, linux openvz). Просто пример того, как нельзя делать. В способ распространения и деплоя софта докер превратили уже потом, те самые девляпсы.
Здравствуйте, smeeld, Вы писали:
S>Нет. Софт должен распростарняться в пакетах под конкретную ОС. Деплоить софт вместе с образами системного окружения ОС-это эра засилья безмозглых девляпсов. Докер-это прежде всего система контейнерной виртуализации и изоляции приложений. Самая худшая из всех, которые сть (solaris zone, freebsd jail, linux openvz). Просто пример того, как нельзя делать. В способ распространения и деплоя софта докер превратили уже потом, те самые девляпсы.
Да вы спорите с какими-то своими тараканами. Напомню, что разговор про тестовые задания. С учетом того, что в плюсовом мире нет станадартов на сборку и управление зависимостями, предоставление готового образа для демонстрации это признак вежливости и профессионализма.
Здравствуйте, Skorodum, Вы писали:
>С учетом того, что в плюсовом мире нет станадартов на сборку и управление зависимостями, предоставление готового образа для демонстрации это признак вежливости и профессионализма.
Предоставить rpm и rpms, или deb пакеты. Это всё, что нужно.
Здравствуйте, smeeld, Вы писали:
S>Предоставить rpm и rpms, или deb пакеты. Это всё, что нужно.
Для системного софта — норм, для прикладного — не, лучше контейнер.
Иначе будешь потом все эти rpm/deb переделывать на каждый чих при обновлениях ОС (в т.ч. минорных)
Здравствуйте, smeeld, Вы писали:
S>Предоставить rpm и rpms, или deb пакеты. Это всё, что нужно.
Категоричное утверждение.... В вашем мире розовых понигиков:
1. На винде и маке разработки не ведется?
2. Всегда есть все необходимые версии?
3. Нет никаких конфликтов с уже установленными пакетами?
Здравствуйте, Skorodum, Вы писали:
S>Категоричное утверждение.... В вашем мире розовых понигиков:
Так в мире софта для тырпрайза, а не всякой модномолодёжной эфемерной чухни.
S>1. На винде и маке разработки не ведется?
Линуксы и юниксы.
S>2. Всегда есть все необходимые версии?
Всегда. Синдромом тащить на каждый чих новомодную либу самой распоследней версии никто не страдает в принудительном порядке.
S>3. Нет никаких конфликтов с уже установленными пакетами?
В рамках мажорных версий дистров каждой из используемых ОС нет. Ибо используются только штатные пакеты дистра.
совсем не эфемерные радары, разработчики сидят на всех платформах и используем мы 5 разных компиляторов.
S>>1. На винде и маке разработки не ведется? S>Линуксы и юниксы.
Ну так это 5-10% разработчиков максимум.
S>>2. Всегда есть все необходимые версии? S>Всегда. Синдромом тащить на каждый чих новомодную либу самой распоследней версии никто не страдает в принудительном порядке.
Ну вот например, Matlab это новомодная либа?
S>>3. Нет никаких конфликтов с уже установленными пакетами? S>В рамках мажорных версий дистров каждой из используемых ОС нет. Ибо используются только штатные пакеты дистра.
Это в теории, а на практике при более-менее сложно разработке конфликты очень часто бывают и нервы сильно портят.
совсем не эфемерные радары, разработчики сидят на всех платформах и используем мы 5 разных компиляторов.
Хочу рассказать о норвежском высокотехнологичном стартапе: Novelda.
Как раз оно самое и есть, ефемерное и модномолодёжное. Тема может и не молодёжная, но сам проект просто истекает смузями.
S>Ну так это 5-10% разработчиков максимум.
Это компании, владеющие 95%-ами фин. ресурсов планеты, и на которые приходится столько же процентов оборота в IT.
S>Ну вот например, Matlab это новомодная либа?
Мы о серверном или о десктоповом софте говорим? Я о серверном.
S>Это в теории, а на практике при более-менее сложно разработке конфликты очень часто бывают и нервы сильно портят.
Только если пользоваться пакетами из васянских реп. При использовании пакетов из штатных реп такого не бывает.
