А можно полслова про реализацию?
GraphQL выглядит волшебно! Мне frontend мне уши про него прожужжал. Но, как его реализовывать на backend? Или, по сути, это всего лишь batch mode для чего-то вроде REST?
На сколько это усложняет жизнь backend разработчиков?
или там за деньги, или в mysql шаридинг вручную и неизвестно, что «дешевле» :)
но при таких объемах можно и правда не дергаться… 80Гиг за год — это не много…
Мне казалось, хранить логи в БД — не самый лучший вариант. Почему не использовать какое-нибудь специфическое решение. Например, influxdb или graphit с последующим натягиванием какой-нибудь grafana?
Вы это всё использовали или это список из разряда — что нагуглилось, то и написал?
JUnit — framework для тестирования, альтернатив ему — миллион. Хотя, пожалуй, и самый популярный. Но назвать его инструментом можно с большой натяжкой. Вот какой-нибудь allure — инструмент.
В выявлении ошибок приведена дорогущая Jira, но нет того же youtrack, redmine и подобных.
Еще можно вспомнить ту же pvs-studio и ряд других статических анализаторов.
Вообще, большой вопрос вызывает даже сам принцип группировки инструментов. У вас в написании кода и редакторы и генераторы и разработка API (тут можно было про swagger вспомнить).
И, еще один большой вопрос, никак не упомянутый в статье (но пожалуй, самый интересный): как это все между собой интегрировать?
tidy работает, есть еще пара вопросов.
Где можно посмотреть, что процесс идет (это глаз справа вверху?)
Можно ли отключить ваш встроенный анализатор и оставить только tidy и проверку синтаксиса. А то, ваш анализатор C++17 не понимает (в частности инициализацию свойств через '='), и генерит ложные срабатывания — приходится на него забивать.
Повторюсь, vim мне нравится, я им пользуюсь. Но, например, межфайловая навигация в нем — ужасна. Копирование через буфер обмена — тоже та еще рулетка. Нет, всё решаемо, но требует определенного напряжения.
Да, я пишу софт для настройки этой самой ОС и обертки тут не всегда помогают. Отсюда же нежелание запускать что-либо на своей ОС — можно поиметь кучу лишнего геморроя. Даже, когда вместо Mac у меня был Linux, я так не делал.
В процессе экспериментов в ОС скапливается туча ненужных пакетов и каких-то настроек. Создается неповторимое окружение, которое порождает неповторимые сборки (про запуск я вообще молчу). Это как раз тот случай, когда только у разработчика «всё работает».
Просто, статья не про настройку vim. Я пользовался YCM. У меня есть конфиг для vim, который я, как правило, просто копировал на новое место (+установка некоторого количества плагинов, типа YCM). Как правило проблемы начинаются, когда требуется сложная навигация между файлами. Попробуйте поискать какое-нибудь имя по всему проекту? grep? Может конечно есть плагин. Но сколько сочетаний клавиш вы храните в памяти постоянно? Если забыл — никакого контекстного меню, только хардкор! Я даже, одно время autocomplete не пользовался — память тренировал, пока с boost не столкнулся :)
macOS — это FreeBSD, а это совсем не linux. Например, там нет proc, абсолютно другая логика работы с shared library ну и еще по мелочам, которые, тем не менее, вполне могут испортить жизнь. + я не люблю засорять собственную ОС, предпочитая работать через chroot, virtualbox или docker.
Потому что, это, как ни крути, изменения проекта чисто под себя, чего я делать не хотел.
Возможно я не совсем точно сформулировал мысль. Да, при добавлении новый файлов cmake отрабатывает дольше, за счет двойной работы. Но это небольшая плата за возможность экономить 50% времени, при отладке.
ЗЫ
Я не против vim, до сих пор кое что правлю в нем. Его, в отличие от CLion, можно легко запустить удаленно. Он быстрее грузится. Глупо открывать проект в CLion, чтобы поправить пару строк :)
Я думал о нем, но не встретил ни одного человека, который бы мне сказал — это круто, попробуй!
Зато многие отговаривали. В общем, имидж у него не очень :)
> Что значит читать настройки автоматически? Откуда?
/Applications/CLion.app/Contents/bin/clang/clang-tidy --help
…
-config= —
Specifies a configuration in YAML/JSON format:
-config="{Checks: '*',
CheckOptions: [{key: x,
value: y}]}"
When the value is empty, clang-tidy will
attempt to find a file named .clang-tidy for
each source file in its parent directories.
Я сегодня статью запостил, что для этого делаю я — может опубликуют в песочнице.
В двух словах, для вас гению через make, а для сборки использую ninja :)
А почему бы автоматически не читать настройки tidy из .clang-tidy?
У меня проверка на tidy делается на каждый push. Специально сделал пару ошибок. Как увидеть результат tidy в CLion? Когда вы его прогоняете (он ведь довольно медленный)?
Еще у вас всплывающие внизу справа уведомления жрут 100% CPU, пока их не закроешь :)
Выглядит прикольно! Сам иногда блок-схемы рисую, когда случай шибко замороченный. Но, в них я не пытаюсь весь код один в один отобразить.
Так что, во первых, исходя из примеров, графическое представление будет занимать больше места на экране.
В этом случае, не вижу в нем смысла.
Во вторых, по сути, грамотная подсветка синтаксиса сделает практически тоже самое.
Как пример: видел кучу программ, которые автоматически рисуют схемы для реляционной БД. Как показывает практика эти схемы в лучшем случае надо допиливать вручную, в худшем — выкидывать и рисовать самостоятельно.
P.S.
И что только люди не придумают, чтобы не обрамлять блоки :)
Но в любом случае, успехов вам! В качестве академического проекта — очень даже интересно.
GraphQL выглядит волшебно! Мне frontend мне уши про него прожужжал. Но, как его реализовывать на backend? Или, по сути, это всего лишь batch mode для чего-то вроде REST?
На сколько это усложняет жизнь backend разработчиков?
но при таких объемах можно и правда не дергаться… 80Гиг за год — это не много…
На какой объем логов вы рассчитываете?
JUnit — framework для тестирования, альтернатив ему — миллион. Хотя, пожалуй, и самый популярный. Но назвать его инструментом можно с большой натяжкой. Вот какой-нибудь allure — инструмент.
В выявлении ошибок приведена дорогущая Jira, но нет того же youtrack, redmine и подобных.
Еще можно вспомнить ту же pvs-studio и ряд других статических анализаторов.
Вообще, большой вопрос вызывает даже сам принцип группировки инструментов. У вас в написании кода и редакторы и генераторы и разработка API (тут можно было про swagger вспомнить).
И, еще один большой вопрос, никак не упомянутый в статье (но пожалуй, самый интересный): как это все между собой интегрировать?
Последний раз я смотрел на него довольно давно — это был жуткий тормоз…
Правда, и CLion поначалу был тот еще тормоз :)
tidy работает, есть еще пара вопросов.
Где можно посмотреть, что процесс идет (это глаз справа вверху?)
Можно ли отключить ваш встроенный анализатор и оставить только tidy и проверку синтаксиса. А то, ваш анализатор C++17 не понимает (в частности инициализацию свойств через '='), и генерит ложные срабатывания — приходится на него забивать.
Повторюсь, vim мне нравится, я им пользуюсь. Но, например, межфайловая навигация в нем — ужасна. Копирование через буфер обмена — тоже та еще рулетка. Нет, всё решаемо, но требует определенного напряжения.
Да, я пишу софт для настройки этой самой ОС и обертки тут не всегда помогают. Отсюда же нежелание запускать что-либо на своей ОС — можно поиметь кучу лишнего геморроя. Даже, когда вместо Mac у меня был Linux, я так не делал.
В процессе экспериментов в ОС скапливается туча ненужных пакетов и каких-то настроек. Создается неповторимое окружение, которое порождает неповторимые сборки (про запуск я вообще молчу). Это как раз тот случай, когда только у разработчика «всё работает».
macOS — это FreeBSD, а это совсем не linux. Например, там нет proc, абсолютно другая логика работы с shared library ну и еще по мелочам, которые, тем не менее, вполне могут испортить жизнь. + я не люблю засорять собственную ОС, предпочитая работать через chroot, virtualbox или docker.
Потому что, это, как ни крути, изменения проекта чисто под себя, чего я делать не хотел.
Возможно я не совсем точно сформулировал мысль. Да, при добавлении новый файлов cmake отрабатывает дольше, за счет двойной работы. Но это небольшая плата за возможность экономить 50% времени, при отладке.
ЗЫ
Я не против vim, до сих пор кое что правлю в нем. Его, в отличие от CLion, можно легко запустить удаленно. Он быстрее грузится. Глупо открывать проект в CLion, чтобы поправить пару строк :)
Зато многие отговаривали. В общем, имидж у него не очень :)
В данном случае он был добавлен скорее по привычке — обычно проблем от него нет.
/Applications/CLion.app/Contents/bin/clang/clang-tidy --help
…
-config= —
Specifies a configuration in YAML/JSON format:
-config="{Checks: '*',
CheckOptions: [{key: x,
value: y}]}"
When the value is empty, clang-tidy will
attempt to find a file named .clang-tidy for
each source file in its parent directories.
В двух словах, для вас гению через make, а для сборки использую ninja :)
У меня проверка на tidy делается на каждый push. Специально сделал пару ошибок. Как увидеть результат tidy в CLion? Когда вы его прогоняете (он ведь довольно медленный)?
Еще у вас всплывающие внизу справа уведомления жрут 100% CPU, пока их не закроешь :)
Так что, во первых, исходя из примеров, графическое представление будет занимать больше места на экране.
В этом случае, не вижу в нем смысла.
Во вторых, по сути, грамотная подсветка синтаксиса сделает практически тоже самое.
Как пример: видел кучу программ, которые автоматически рисуют схемы для реляционной БД. Как показывает практика эти схемы в лучшем случае надо допиливать вручную, в худшем — выкидывать и рисовать самостоятельно.
P.S.
И что только люди не придумают, чтобы не обрамлять блоки :)
Но в любом случае, успехов вам! В качестве академического проекта — очень даже интересно.
Мне показалось, статья не про это…