уволенные тратили в канале с мемами «слишком много рабочего времени», а формат этих шуток был неэтичным. При этом компания не против неформального общения работников в рабочих чатах
Дело не в том, что сотрудники сами по себе чатились, как выяснилось
Заметьте, я в своем комментарии ни слова про профессионализм разработчиков не сказал.
Есть просто огромная разница даже между
«три джуна коммитят в одну репу» и «три джуна проводят обязательное код ревью друг друга». Даже при условии отсутствии опыта результат совершенно разный (ну только если три джуна это три брата близнеца разве что), просто за счет того что люди мыслят и видят все по-разному.
К сожалению, я не нашел git репозитория данного проекта, на сайте только tarболлы. Поэтому не могу сделать далекоидущих выводов о коллективной разработке; но поисследовав с десяток файлов, ощущение что у одного файла обычно не больше 2 авторов. Т.е. могу сделать предположение, что разработка ведется по следующей схеме:
— имеется директория со всей библиотекой;
— один из сотрудников университета решает расширить функциональность
— пишет новый класс, добавляет к нему автотесты, пишет документацию
— после сдачи статьи/диссертации код продолжает лежать мертвым грузом
В лучшем случае придет человек который решит исправить какие-то нюансы реализации.
Повторюсь, это лишь мои домыслы.
Что интересно, я не нашел в коде использований STL. вообще.
Вы это все про 2017 студию? Процесс установки очень сильно доработан был при переходе к 2017 версии (в 2015 при установке на 7 да, я тоже огребал с этой кучей обновлений и перезагрузок. В какой-то момент установщик решил обновить IE и почему-то не смог)
Проекту можно только посочувствовать. Да, можно разработчикам порекомендовать статический анализ, но этого явно мало, если в проекте на С++ (не С даже) появляются конструкции вида
Это явно говорит о системных проблемах: отсутствие внятного стиля и практик кодирования, видимо отсутствие культуры ревью.
Другие примеры только подтверждают это наблюдение. (авторы Cpp Core Guidelines заплакали)
Да, культура написания кода не исключит все ошибки (но 9/10 явно можно будет избежать). Для остального уже стат анализаторы придут на помощь :)
Что значить не стало прошлым? Не так часто люди ищут новую работу, еще не уволившись с предыдущей.
Минусов мне так понимаю насовали за мнение «нормальная реакция HR».
Что вас развеселило? У вас не было такого опыта? Ну это не значит что такого не существует. По-моему это нормальная реакция HR — позвонить на прошлое место работы, мол «а правда ли такой-то такойтович от вас ушел потому что вы ему мало платили?»
у меня вот рекомендации с прошлого места работы запрашивали
В win вообще многие вещи «не очень». Ваши предложения по этому поводу?
Обычно все зависимости передаются скрипту конфигурирования в качестве параметров.
1. CMD: в случае autotools/cmake — это параметры/дефайны командной строки. в случае QBS — сеттеры для qml-объектов.
2. GUI, QtC: в случае cmake — есть настройка параметров cmake через редактирование (если они помечены как set… CACHE или option), либо через добавление через GUI. Наряду, кстати с переменными среды. В случае QtC/qbs, это тоже задается через вкладку сборки.
3. Qtc. Если лень в каждую конфигурацию их прописывать, их можно прописать в настройки тулчейна (опять же работает для cmake/qbs) а для QMake — создать отдельный mkspec где нафигачить все переменные которые вам нужны и легко и непринужденно так же указать в kit-е.
4. тот же qtc, в исключительных случаях можно поправить переменные среды (!) во вкладке сборки проекта (все типы систем сборки). Это если ничего не помогло
про другие IDE тоже могу рассказать. Но нигде что-то не встречал я рекомендации «давайте прописывать глобально в системе». Простите, а если я вот хочу две версии мажорных OSG параллельно отлаживать? 2 набора переменных создавать? Постоянно там значения крутить?
Так что я не согласен с вашим выпадом мол на win все такое убогое.
На ваш взгляд не может, а на чей-нибудь другой взгляд — вполне
Ну вот я специально и вставляю оборот, что на мой взгляд, я свое мнение не только высказываю, но и аргументирую. Я же не прошу автора идти совершать соударения со стенами и удалять статью? По-моему вы в этом вопрос слишком болезненно восприняли критику. Кому-то будет полезно — хорошо. Если будут еще публикации — тоже замечательно.
Про CMake и Qtc — не впервой встречаю эту мантру) Тут согласен, что объективной грани нет. Я просто лично не сталкивался с разработчиками, которые пользовались более чем одной системой конфигурирования и при этом признаются что на qmake им писать нравится.
Но!) Хочу с вами поделиться личным опытои: имею множество проектов на CMake, как на работе, так и для личных нужд. При этом не испытываю особых сложностей через добавление в проект файлов с помощью шаблонов (Ctrl+N, Add C++ Class). Да, есть мелкое неудобство что пункт задизаблен в контекстном меню директории проекта. Но это пожалуй все. Открыт у меня какой-то файл, в директории project/foo/bar, нажимаю ctrl+N, выбираю шаблон, он добавляется сразу в foo/bar.
После этого вызываю run cmake (он у меня на хоткей забинден), поэтому сказать что прям IDE заставляет меня страдать — не могу (все это занимает считанные секунды).
Да, люди имеют проекты в которых перечислены файлы, но даже в вашем примере это не так — используется матчинг файлов через $$files. Собственно, для проектов в которых нет глоббинга файлов в любом виде — мой рецепт не поможет =)
Мое личное мнение (как человека, начавшего изучение С++ именно с С) — это неудачный совет. Страуструп хорош, как фундаментальный учебник для человека, замечателен как справочник, как настольная книга, когда начинаешь курить новые конструкции.
Но вот прям как самоучитель для начинающих… увольте. Мне кажется, должны быть альтернативы получше, иначе если не зайдет, у человека вообще может желание изучать язык отбить.
Прописывать переменные окружения системы — это из оф мануала такой совет? Выглядит… вообще не очень.
Так же есть легкое пожелание по поводу QMake. Qt официально объявили что главной системой сборки будет CMake. Поэтому крайне желательно современные мануалы адаптировать под него (стандарт де-факто будет сильно грубо сказать?)
Не потому что qmake фу (хотя я бы мог и так сказать), просто подключение внешних таких зависимостей имхо через cmake удобнее и проще чем через qmake. По моему лишь опыту.
(void) argc;
(void) argv;
use [[maybe__unused]], Luke.
#ifndef MAIN_H
я понимаю есть пуристы, которые набегут и скажут «в стандарте нет никаких ваших #pragma», но лично я их чаяних не разделяю. Если ты не пишешь код который должен работать на 98 платформах, вряд ли стоит отказываться от удобной "#pragma once"
Далее… немного о полезности самой статьи.
Я сомневаюсь что на Хабре найдется много программистов, пишущих на С++, которые не смогут самостоятельно собрать cmake проект. Если никаких нюансов вроде «надо обязательно задать опцию дин. рантайма, иначе нихрена не соберется», то и смысла в статье немного. (разве что ну оооочень начинающим).
Ну и по итогу вся статья в выжимке — сокращается до hello world'a, без каких-то побуждений, что можно делать дальше. Стартовым толчком, на мой взгляд, она служить не может.
Все вышесказанное это только взгляд «как это ощущается» и точно не унижение достоинств автора.
Да вроде вы пишете (и автор) правильные вещи. Но это мое мнение — это все не стоит статьи.
То что не заметил что перевод — целиком мой косяк, каюсь, претензии безосновательны — уж больно не ожидал увидеть перевод в этом блоге =)
Перевод с точки зрения сохранения смысла хороший. Но сам материал не стоящий. Вот так, уж простите.
Еще варианты над которыми я думал:
1. вместо рекурсии — порождать новый процесс, передавать ему хендл на ту же консоль, а текущий процесс завершать
2. примерно то же самое можно попробовать с потоками, но я чет зафейлил задачу по join-у thread из следующего в цепочке (но вроде формально это не запрещено).
Т.о. цикл будет за счет средств порождения нового потока/процесса.
Хз насколько это соответствует условию «нет скрытых условий», ибо в ОС этих условий дофига, но в коде программы вроде как и нет
Ну чего вы придираетесь? Это мем. Можете вбить «Крымчанка, дочь офицера». Простите если нарушил принятый на хабре официальный стиль, но не стоило на этом делать акцент
ну лидер только в смысле «в первых трех местах» :D
Что я считаю важного MS сделала с последней версией — то что она сделала бинарную совместимость между двумя версиями компилятора. Это просто ключевой момент, на мой взгляд — разработчикам больше не нужно ждать, «когда же vendorname запилит поддержку нового VC», можно просто брать и использовать скомпиленную под 2015 библиотеку (да, в большинстве случаев оно и в новой версии собирается, но увы не всегда)
Ну вот и не вижу противоречия:)
Допустим в компании 50 разработчиков под Win, и пусть половина из них не согласна расстаться с VS. Пусть сейчас они пользуются VS 2015. Предположим на секунду, что и вправду для использования Build Tools достаточно приобрести 1 лицензию на VS (в чем сомневаюсь, еще раз). Но все равно это означает что для перехода на новую версию компилятора где-то надо выложить деньга на 25 лицензий VS 2017) И даже если руководство в целом одобряет такие траты, нужно как-то доказать что они оправданы, пусть даже без чиселок с графиками и прочего ROI булшита)
Дело не в том что руководство запрещает что-то использовать, скорее наоборот в предоставлении этой самой свободы.
(и да, я даже не буду обсуждать вариант «а давайте только части разработчиков новую версию дадим», это еще хуже чем не обновлять ничего вовсе)
Ага, в компиляторе они допустим есть, но попробуйте с ними собрать проект под CMake скажем, без лишних телодвижений) Я лично пока не вижу способов не хардкодить зависимости для каждого файла (плюс прощай распределённая сборка на N машин). Не все так просто (я сама дочь девопс инженера)
Дело не в том что это нельзя «пощупать». Дело в том что внедрить это в сколько-то значимых масштабах — боль.
Дело не в том, что сотрудники сами по себе чатились, как выяснилось
Есть просто огромная разница даже между
«три джуна коммитят в одну репу» и «три джуна проводят обязательное код ревью друг друга». Даже при условии отсутствии опыта результат совершенно разный (ну только если три джуна это три брата близнеца разве что), просто за счет того что люди мыслят и видят все по-разному.
К сожалению, я не нашел git репозитория данного проекта, на сайте только tarболлы. Поэтому не могу сделать далекоидущих выводов о коллективной разработке; но поисследовав с десяток файлов, ощущение что у одного файла обычно не больше 2 авторов. Т.е. могу сделать предположение, что разработка ведется по следующей схеме:
— имеется директория со всей библиотекой;
— один из сотрудников университета решает расширить функциональность
— пишет новый класс, добавляет к нему автотесты, пишет документацию
— после сдачи статьи/диссертации код продолжает лежать мертвым грузом
В лучшем случае придет человек который решит исправить какие-то нюансы реализации.
Повторюсь, это лишь мои домыслы.
Что интересно, я не нашел в коде использований STL. вообще.
Это явно говорит о системных проблемах: отсутствие внятного стиля и практик кодирования, видимо отсутствие культуры ревью.
Другие примеры только подтверждают это наблюдение. (авторы Cpp Core Guidelines заплакали)
Да, культура написания кода не исключит все ошибки (но 9/10 явно можно будет избежать). Для остального уже стат анализаторы придут на помощь :)
Минусов мне так понимаю насовали за мнение «нормальная реакция HR».
у меня вот рекомендации с прошлого места работы запрашивали
Обычно все зависимости передаются скрипту конфигурирования в качестве параметров.
1. CMD: в случае autotools/cmake — это параметры/дефайны командной строки. в случае QBS — сеттеры для qml-объектов.
2. GUI, QtC: в случае cmake — есть настройка параметров cmake через редактирование (если они помечены как set… CACHE или option), либо через добавление через GUI. Наряду, кстати с переменными среды. В случае QtC/qbs, это тоже задается через вкладку сборки.
3. Qtc. Если лень в каждую конфигурацию их прописывать, их можно прописать в настройки тулчейна (опять же работает для cmake/qbs) а для QMake — создать отдельный mkspec где нафигачить все переменные которые вам нужны и легко и непринужденно так же указать в kit-е.
4. тот же qtc, в исключительных случаях можно поправить переменные среды (!) во вкладке сборки проекта (все типы систем сборки). Это если ничего не помогло
про другие IDE тоже могу рассказать. Но нигде что-то не встречал я рекомендации «давайте прописывать глобально в системе». Простите, а если я вот хочу две версии мажорных OSG параллельно отлаживать? 2 набора переменных создавать? Постоянно там значения крутить?
Так что я не согласен с вашим выпадом мол на win все такое убогое.
Ну вот я специально и вставляю оборот, что на мой взгляд, я свое мнение не только высказываю, но и аргументирую. Я же не прошу автора идти совершать соударения со стенами и удалять статью? По-моему вы в этом вопрос слишком болезненно восприняли критику. Кому-то будет полезно — хорошо. Если будут еще публикации — тоже замечательно.
Про CMake и Qtc — не впервой встречаю эту мантру) Тут согласен, что объективной грани нет. Я просто лично не сталкивался с разработчиками, которые пользовались более чем одной системой конфигурирования и при этом признаются что на qmake им писать нравится.
Но!) Хочу с вами поделиться личным опытои: имею множество проектов на CMake, как на работе, так и для личных нужд. При этом не испытываю особых сложностей через добавление в проект файлов с помощью шаблонов (Ctrl+N, Add C++ Class). Да, есть мелкое неудобство что пункт задизаблен в контекстном меню директории проекта. Но это пожалуй все. Открыт у меня какой-то файл, в директории project/foo/bar, нажимаю ctrl+N, выбираю шаблон, он добавляется сразу в foo/bar.
После этого вызываю run cmake (он у меня на хоткей забинден), поэтому сказать что прям IDE заставляет меня страдать — не могу (все это занимает считанные секунды).
Да, люди имеют проекты в которых перечислены файлы, но даже в вашем примере это не так — используется матчинг файлов через $$files. Собственно, для проектов в которых нет глоббинга файлов в любом виде — мой рецепт не поможет =)
Но вот прям как самоучитель для начинающих… увольте. Мне кажется, должны быть альтернативы получше, иначе если не зайдет, у человека вообще может желание изучать язык отбить.
Так же есть легкое пожелание по поводу QMake. Qt официально объявили что главной системой сборки будет CMake. Поэтому крайне желательно современные мануалы адаптировать под него (стандарт де-факто будет сильно грубо сказать?)
Не потому что qmake фу (хотя я бы мог и так сказать), просто подключение внешних таких зависимостей имхо через cmake удобнее и проще чем через qmake. По моему лишь опыту.
(void) argc;
(void) argv;
use [[maybe__unused]], Luke.
#ifndef MAIN_H
я понимаю есть пуристы, которые набегут и скажут «в стандарте нет никаких ваших #pragma», но лично я их чаяних не разделяю. Если ты не пишешь код который должен работать на 98 платформах, вряд ли стоит отказываться от удобной "#pragma once"
Далее… немного о полезности самой статьи.
Я сомневаюсь что на Хабре найдется много программистов, пишущих на С++, которые не смогут самостоятельно собрать cmake проект. Если никаких нюансов вроде «надо обязательно задать опцию дин. рантайма, иначе нихрена не соберется», то и смысла в статье немного. (разве что ну оооочень начинающим).
Ну и по итогу вся статья в выжимке — сокращается до hello world'a, без каких-то побуждений, что можно делать дальше. Стартовым толчком, на мой взгляд, она служить не может.
Все вышесказанное это только взгляд «как это ощущается» и точно не унижение достоинств автора.
вот пример на мой взгляд ДЕЙСТВИТЕЛЬНО хорошего Hello World:
habr.com/company/newprolab/blog/328422
То что не заметил что перевод — целиком мой косяк, каюсь, претензии безосновательны — уж больно не ожидал увидеть перевод в этом блоге =)
Перевод с точки зрения сохранения смысла хороший. Но сам материал не стоящий. Вот так, уж простите.
недавно смотрел доклад с cppcon, один из слайдов был «а что ж такое этот самый modern C++», ощущение что вот просто оттуда все взято.
1. вместо рекурсии — порождать новый процесс, передавать ему хендл на ту же консоль, а текущий процесс завершать
2. примерно то же самое можно попробовать с потоками, но я чет зафейлил задачу по join-у thread из следующего в цепочке (но вроде формально это не запрещено).
Т.о. цикл будет за счет средств порождения нового потока/процесса.
Хз насколько это соответствует условию «нет скрытых условий», ибо в ОС этих условий дофига, но в коде программы вроде как и нет
Что я считаю важного MS сделала с последней версией — то что она сделала бинарную совместимость между двумя версиями компилятора. Это просто ключевой момент, на мой взгляд — разработчикам больше не нужно ждать, «когда же vendorname запилит поддержку нового VC», можно просто брать и использовать скомпиленную под 2015 библиотеку (да, в большинстве случаев оно и в новой версии собирается, но увы не всегда)
Допустим в компании 50 разработчиков под Win, и пусть половина из них не согласна расстаться с VS. Пусть сейчас они пользуются VS 2015. Предположим на секунду, что и вправду для использования Build Tools достаточно приобрести 1 лицензию на VS (в чем сомневаюсь, еще раз). Но все равно это означает что для перехода на новую версию компилятора где-то надо выложить деньга на 25 лицензий VS 2017) И даже если руководство в целом одобряет такие траты, нужно как-то доказать что они оправданы, пусть даже без чиселок с графиками и прочего ROI булшита)
Дело не в том что руководство запрещает что-то использовать, скорее наоборот в предоставлении этой самой свободы.
(и да, я даже не буду обсуждать вариант «а давайте только части разработчиков новую версию дадим», это еще хуже чем не обновлять ничего вовсе)
Дело не в том что это нельзя «пощупать». Дело в том что внедрить это в сколько-то значимых масштабах — боль.