• Онлайн тестирование — вы серьезно?
    0
    Вам передают привет почти все крупные фирмы в США

    Спасибо. Не только крупными фирмами США живы, как говориться. :) Так то я в сети и на конференциях самые разнообразные примеры видел.
  • Онлайн тестирование — вы серьезно?
    0
    Будет работать только с теми компаниями, руководство которых не параноит по поводу доступа к исходникам «третьих лиц» в таком вот режиме.
  • Онлайн тестирование — вы серьезно?
    0
    С каких пор «некоторые» стали эквивалентном «всех», а? :) И, честно говоря, про гугл первый раз такое слышу. Так то можно и ещё более суровые примеры взять: игровое подразделение Sony запрещает своим геймдизам любую профессиональную активность, не связанную с дизайном игр, которые они делают по работе. То есть попилить что-то своё дома — это хороший способ лишиться работы и попасть под суд за нарушение NDA.
  • Онлайн тестирование — вы серьезно?
    0
    Там должно было быть «личное». Я поправил. В плане рабочего — некоторые работодатели могут позволить работать на OSS-проектами и в рабочее время. Но тут звёзды должны определённым образом сойтись.
  • Онлайн тестирование — вы серьезно?
    0
    Тьфу, конечно личное. :) Поправил.
  • Онлайн тестирование — вы серьезно?
    0
    Тут как бы такой момент: адекватного работодателя не должно заботить, как именно сотрудник тратит своё личное время. А от неадекватных лучше держаться подальше — это раз. Второе: собственные проекты позволяют прокачивать скилы и пробовать технологии, которые не позволяет прокачать/потрогать работодатель. Грубо говоря, программист устраивается на работу и попадает в суровый C++-легаси. Такой, 90-ых годов выдержки. Но чтобы не потерять навыки и продолжать быть востребованным на рынке — он, по сути, вынужден работать над своими проектами так, и с такими технологиями, которые позволяют ему оставаться востребованным. Это, в общем, нормально.
  • Онлайн тестирование — вы серьезно?
    0
    Я знаю далеко не одного разработчика (некоторых — лично), которые работают в топовых мировых или российских компаниях и параллельно тащат свои open-source-проекты. Иногда с поддержкой компании, иногда — без оной. Проекты, хорошо известные в коммьюнити. Увольнять их, вроде, пока никто не собирается.
  • Jinja2 в мире C++, часть третья. «Теперь ты в конане»
    0
    Да.
  • Онлайн тестирование — вы серьезно?
    0
    Из собственного опыта таких интервью могу заключить, что громкое «problems solving», которое они, типа, проверяют, сводится к тупому «знаешь/не знаешь». Потому что если не знаешь — то есть высокий шанс, что уткнёшься в sub-optimal-решение, не учтёшь какие-то corner case'ы, о которых, разумеется, знает интервьюер, и совершишь ещё кучу подобных ошибок.
  • Онлайн тестирование — вы серьезно?
    +1
    В том то и дело, что на решение таких задач можно натренироваться. Если есть время и желание. О реальном опыте умение их решать не говорит ничего.
  • Шаблоны третьего порядка, или как я портировал Jinja2 на C++
    0

    Частичный ответ на первый вопрос: https://jinja2cpp.dev/docs/j2_compatibility.html#jinja2c-performance

  • Jinja2 в мире C++, часть третья. «Теперь ты в конане»
    +1

    Со стандартом, по идее, да. Должно. Но мне ничего на замену не предложили. С разархивацией — там всё внутри и решается. Обычно метод sources гораздо более кучерявый для проектов, качаемых из репозиториев и т. п. Но так — да, в целом, груз мультиплатформенности даёт о себе знать.

  • Jinja2 в мире C++, часть третья. «Теперь ты в конане»
    0

    Общее для всех проектов только блок метаинфы с настройками и метод получения исходников. Остальное — специфичное. Про подводные камни… Тут есть специфичные для conan-center, о них рассказал, и общие для конан-рецептов вообще. Тут не про все рассказал, да. Но это — тема отдельного материала.

  • Jinja2 в мире C++, часть третья. «Теперь ты в конане»
    0

    Да, всё так. Но вот про скорость принятия не скажу точно. Команда у них небольшая, поэтому может висеть долго. Но можно попинать по альтернативным каналам, чтобы быстрее было.

  • Онлайн тестирование — вы серьезно?
    0
    Компанией, очевидно. :) Её руководством и HR-отделом.
  • Онлайн тестирование — вы серьезно?
    0
    Тут не столько в хантерах дело, сколько в выстроенной системе отбора кандидатов. Хотя, иногда и в хантерах. Из недавнего. Другая контора (буржуйская). Собеседовался в неё год назад и вот сейчас. Год назад — адекватный подход, релевантная тестовая задача, потом onsite, все друг от друга в восторге, но не сговорились по з/п — не срослось. В этом году — «пройдите онлайн-тест». На этом всё и закончилось. :D
  • Онлайн тестирование — вы серьезно?
    0
    А я сталкивался с ситуацией, когда тебя пытаются схантить, при этом тащат через вот этот вот общий фильтр. И это было не рекрутинговое агенство. То есть приходят, поют в почту дифирамбы про опыт, подходящие позиции и прочий буллшит, а потом: «Ну вы это, давайте, вот тут у нас так, надо парочку задачек решить...» И потом: «Ну… Тут в общем такое дело… Давайте вы к нам придёте через полгодика, подготовившись». И ты такой: лолшто? Камон, вы пару недель назад сами ко мне пришли на работу к себе переманивать! Значит, чем-то заинтересовал? Но вы про это даже говорить не стали!
  • Онлайн тестирование — вы серьезно?
    0
    Угу. Всё так. Только изначально (в статье) речь шла о фильтрующих тестах. То есть не прошёл — всё, свободен. По крайней мере я понял именно так.
    Подходит кандидат на позицию или нет можно выяснить следующим образом:
    1) Обладает ли кандидат необходимыми для позиции навыками (выясняется резюме, собеседованием, релевантными задачами и косвенными способами).
    2) Испытательный срок, в процессе которого п. 1 проходит подтверждение (или опровергается).
    Ну, это то, чем я руководствуюсь.
  • Онлайн тестирование — вы серьезно?
    0
    А еще бывают люди, которые считают, что алгоритмические задачки подобны катам — просто разминка для ума.

    Бывают. А бывают люди, которые любят таким образом ум разминать в комфортной обстановке, а не в ситуации дикого time pressure и малознакомом окружении. :) Есть люди, которые любят ум разминать совсем другими задачами. Есть ещё 100500 типов людей, которые такое не пройдут просто потому, что.
  • Онлайн тестирование — вы серьезно?
    0
    Ну, одних просят SQL-запросы составить. Других — что-нибудь с векторами-строками поделать. Зависит от области. На самом деле всё это сводится к одному: собеседование должно быть релевантно реальным требованиям позиции и предполагаемому (по резюме) опыту кандидата. Как-то так. Но такое собеседование предполагает индивидуальный подход, что не все могут (хотят?) себе позволить.
  • Онлайн тестирование — вы серьезно?
    +1
    Нет. Лично мне на них пофиг. Вот на github-аккаунт с публичными репозиториями — уже нет. Хотя там, выше, в камментах, кто-то и не очень жаждет его заводить. На статьи здесь, на хабре, на публикации, на выступления на конфах — тоже не пофиг. Но, понятно, далеко не у всех такое есть в анамнезе.
  • Онлайн тестирование — вы серьезно?
    0
    Вот простой вопрос: как алгоритмическая задача в стиле «сделайте с двумя векторами вот такую вот фигню» проверит умение кандидата работать с многопоточным кодом, его знание основных подводных камней акторных архитектур и прочей, гораздо более полезной в хозяйстве фигни? Ну хорошо, мы поняли, что на leetcode и прочих ресурсах он натренировался. А реальные то задачи он умеет решать? Это я сейчас говорю как человек, который занимался подбором и собеседованием кандидатов. Мне вот лично пофиг, может ли кандидат смержить два неотсортированных вектора (погуглит — и сможет). Мне гораздо важнее, чтобы он фигни в коде не написал, от чего потом рейс-кондишены случаются, например. Или buffer overrun'ы по незнанию. А опыт он чаще закопан именно в таких вот тонкостях.
  • Онлайн тестирование — вы серьезно?
    +1
    За пожелание — спасибо. Проблем как таковых нет. :) Но предложенное вряд ли сработает с топовыми международными компаниями. Они вряд ли согласятся — им проще послать и попросить следующего из очереди. :) Вопрос был больше риторический.
  • Онлайн тестирование — вы серьезно?
    0
    Сейчас, в процессе поиска работы, тоже с таким столкнулся. И возник вопрос: а какой именно скилл, полезный для компании, таким образом тестируется? Ответ найти не смог. А поскольку от результата такого теста зависит дальнейшее продвижение по интервью — скилл, получается, ключевой.
  • Метапрограммирование в C++ и русская литература: через страдания к просветлению
    0

    Спасибо!

  • Метапрограммирование в C++ и русская литература: через страдания к просветлению
    0

    Да, полагаю, правильнее так. Но это цитата из оригинального документа. :)

  • Метапрограммирование в C++ и русская литература: через страдания к просветлению
    +1

    Ну вот, собственно, в субботу на C++ Russia буду рассказывать об одном из решений, которое и парсеры IDE смогут прожевать (просто потому, что всё в итоге в явный исходный текст превращается). Сами метаклассы (на уровне компилятора) — сильно сочувствую тем, кто будет это реализовывать.

  • Метапрограммирование в C++ и русская литература: через страдания к просветлению
    +4
    Qt с его moc заточены под конкретные кейсы. Ну и требуют, собственно, Qt и его инфраструктуры. Средство хорошее, работающее, но, на мой взгляд, нишевое. Можно, конечно, было упомянуть в разделе про генерацию кода, но не хотелось сильно объём раздувать.
  • Метапрограммирование в C++ и русская литература: через страдания к просветлению
    +2
    У Java будут свои слабые места. Но другие. Но так то да — для кого-то может быть и проще. Для других — уже нет. Скажем, где-то Java может оказаться неприменимым как инструмент.
  • Jinja2 в мире C++, часть вторая. Рендеринг
    0
    Тут как бы дело в том, что в качестве парсера «входных данных» у меня clang frontend полным ростом. Можно было бы, конечно, сделать биндинг из него в питон или в Lua… Но таки хотелось, чтобы шаблоны выглядели шаблонами, а не программами на питоне/Lua. :)
  • Реализация оператора in в С++
    0
    Ну, можно и оператор индексирования для списка написать. Тут ведь вопрос — нужно ли. :)
  • Реализация оператора in в С++
    0
    Хм. Интересная интерпретация. :) Я думал, что «техническая причина» — это невозможность (техническая) в языке вернуть заведомо невалидное значение независимо от его типа. В С++ такой возможности действительно нет. А то, что я перечислил — это исключительно вопросы контракта. Можно реализовать так, а можно иначе. Принципиальных технический препятствий в языке для любого из вариантов нет.
  • Реализация оператора in в С++
    +2

    Не всё так просто. Сейчас эту техническую составляющую можно убрать — pop может возвращать std::optional. Но такая операция даёт разработчику (by design!) меньше гарантий, чем пара top/pop. Возникает, например, интересный вопрос: что делать, если во время создания копии объекта для возврата из pop возникло исключение? Что делать, если это случилось на этапе создания возвращаемого значения? Гарантировать, что pop всегда будет делаться через move нельзя — для объектов в стеке эта операция может быть попросту не определена. Полагаться на RVO/copy elision тоже не всегда можно.
    В примере с in такая реализация сужает контракт. Работая с итераторами (казалось бы, удобно!) быстро утыкаешься в то, что для ассоциативных контейнеров и сиквенсов они разные. А стоит переключиться на значения — см. выше.

  • Реализация оператора in в С++
    +5

    Хм… Странный подход. Сейчас, вроде, в C++ наметился тренд в сторону функциональной нотации. То есть не key in map, а contains(map, key) например. Но это ладно, это мелочи. В предложенном методе нарушается подход Single Responsibility. Это как если бы в std::stack был метод pop_and_get (например), или pop не только бы извлекал элемент со стека, но и возвращал бы его. Но такого метода нет (можно у Саттера почитать, почему) — и это правильно. Так же и тут: зачем в одном операторе совмещать две разных ответственности? Оператору in оставить возвращаемое значение bool. А то, что хочется, реализуется чуть проще:


    template<typename M, typename K>
    std::optional<typename M::const_iterator> from(const M& m, K&& key)
    {
        auto p = m.find(key);
        if (p != m.end())
             return p;
    
        return std::optional<typename M::const_iterator>();
    }
    
    //...
    
    if (auto res = from(some_map, "cat"))
    {
         std::cout << res->second << std::endl;
    }

    Можно даже optional на значение возвращать, чтобы не только map'ы, но и списки с векторами поддержать.

  • clang и IDE: история о дружбе и недружбе
    0
    Угу. Да. Вижу. github.com/llvm-mirror/clang/blob/4418c5b56fafe30928f418be4eaee39d275628dc/lib/Frontend/FrontendActions.cpp#L157

    На 3.7 мне этот патч приходилось самому класть. А судя по блейму, появилось это не раньше пятой версии.
  • clang и IDE: история о дружбе и недружбе
    0

    Вам спасибо за развёрнутый комментарий. Читать было интересно.


    Описанная картина довольно мрачная и примерно соответствует действительности, но некоторые факты позволяют смотреть в будущее более позитивно

    С моей ТЗ основная проблема в том, что очень сложно (в данном случае) усидеть на двух стульях. Всё-таки задача просто компиляции и задача поддержки IDE — достаточно разные, чтобы можно было эффективно их обьеденить под одной крышкой. Да, интегрируют, да, пользуются, но за прошедшие семь лет развития и того, и другого (а это довольно внушительный срок) — результат не очень впечатляет. По крайней мере меня. :)


    Если не использовать libclang (и не заботиться о том, чтобы работать со старыми стабильными версиями clang-а из коробки), то можно сделать достаточно много через C++ API уже сейчас

    Именно на этом API и сидел. В том числе для того, чтобы исключать лишние преобразования типов и дополнительного менеджмента.


    Зачем — потому что хочется сконцентрироваться на создании крутых фич и полировке функционала, который реально полезен пользователям, а не гнаться за стандартами, творчески перереализовывая огромное количество кода из компилятора.

    Хорошая цель. :) Насколько достижимая — вот вопрос. Но это как раз в тему форка кланга и пиления вполне конкретных фичей, специфичных для IDE, без оглядки на функции компиляции. Кстати, хороший вопрос возник: а что IDE должно делать с constexpr-функциями? А если они сложные и ресурсоемкие? :)


    И libclang, и clangd умеют работать с т. н. "preambles" — это автоматически генерируемые PCH для всей пачки #include-директив, которые идут в начале файла. Работает очень хорошо — если первая подсветка — примерно как компиляция, то последующее редактирование — гораздо приятнее.

    Да. И я даже ходил в эту сторону. Но есть нюанс. Даже два. Первый описан в статье — ошибки в хедере, и создание преамбулы обламывается. А ошибки возникали у меня как-то слишком часто (и в основном в системных заголовках). Второй — pch можно перекомпилировать реже, а польза от него почти такая же. Только в редких проектах исходники включают вязанку заголовков, и все они из project root. Чаще основной объем приходится на библиотеки/фреймворки. А так — да, что pch, что преамбула — это сериализованное AST. Шагов до комбинированния итогового AST из нескольких — совсем чуть чуть осталось. Но для того, чтобы такое комбинированния было возможно — сам clang парсер должен быть глубоко интегрирован в IDE. То есть IDE (та часть, которая занимается обработкой кода — с индексами и прочим) становится как бы фронтендом для библиотек clang'а. Но чтобы так сделать — довольно существенно всё перепиливать надо.

  • clang и IDE: история о дружбе и недружбе
    0
    Я не могу сходу ответить на этот вопрос — надо изучать реализацию. Могу лишь сказать, что наличие возможности в рамках одного проекта работать над исходниками с разными опциями компиляции/тулчейнами (что может серьёзно отражаться на AST) наличие единого сервера для моделей кода исходников становится сомнительным бенефитом. В контексте С++, разумеется. Но, возможно, это проблема как-то решена.
  • clang и IDE: история о дружбе и недружбе
    +2
    Да. Есть такая фича у clang. А теперь история о том, как я её нашёл. В попытках поднять перформанс работы связки IDE + clang я полез смотреть, а на что же clang тратит процессорное время. И довольно быстро обнаружил в первой двадцатке функций алгоритм подсчёта дистанции Левенштейна. «Что за фигня? — думаю, — Зачем?». Полез копаться дальше и наткнулся как раз на алгоритм подбора подходящего идентификатора к «неправильно написанному» в рамках видимого скоупа. Хорошая фича для компилятора. Но при работе в связке с IDE, когда компиляция запускается буквально на каждый чих — эмм… Не уверен. При условии, что невалидных идентификаторов может быть в достатке по тем или иным причинам. Пробежаться по скоупу может может и код, который автокомплит делает, а не FixIt-хинты для найденных ошибок. При работе в связке с IDE, разумеется.
  • clang и IDE: история о дружбе и недружбе
    0
    Всё так. Только начиная с 4.7 clang backend по-умолчанию включен. И, насколько я понял из комментариев к релизу, развивать они дальше будут именно эту ветку, а не самописный парсер.
  • clang и IDE: история о дружбе и недружбе
    0
    Да. Всё так. :) Приходится извращаться.