Держите более компактный вариант решения 3 задачи (план выполнения, думаю, аналогичный).
SELECT
s.department_id,
department_name,
total_employees,
high_earners,
s.high_earners * 100.0 / s.total_employees AS percent_high_earners
FROM (
SELECT
department_id,
COUNT(*) AS total_employees,
SUM(CASE WHEN salary > 100000 THEN 1 ELSE 0 END) AS high_earners
FROM employees
GROUP BY department_id
HAVING (SUM(CASE WHEN salary > 100000 THEN 1 ELSE 0 END) * 100.0 / COUNT(*)) > 10
) s JOIN departments d ON s.department_id = d.department_id
ORDER BY total_employees DESC
LIMIT 3;
К сожалению нет, архитектура Roslyn не разделяет их на разные типы — для анализатора нет никакой разницы, запущен он в IDE или при сборке
Может я не максимально понятно выразился. Для анализатора может и нет, но что мешает написать два анализатора и один настроить для билда, а другой для IDE? В документации есть, сам не пробовал, потому что не требовалось.
P.S. На случай, если новый редактор что-то сотворит со ссылкой, вот названия настроек оттуда:
Кроме того, бритву Хэнлона невозможно кратко сформулировать так, чтобы она учитывала это обстоятельство. Вот даже в статье выше, автор предлагает формулировку
Вариант "не объясняй лишь злонамеренностью то, что вполне объясняется глупостью*" не идеален, но суть передаёт.
Потому что они призваны, на самом деле, только напомнить о противоположной склонности
По поводу "упасть при компиляции" - решается nameof(a).
P.S. Конечно, это не гарантирует, что не окажется поля с таким названием... Вероятность этого можно снизить с помощью StyleCop или чем-то вроде. Сам уже лет 10 пользуюсь для приватных полей подчёркиванием ("_name"), коллег тоже подсадил - все довольны.
Плюсану. Вы очень ёмко выразили основную мысль, которую я сам хотел донести в комментарии ниже. Но у меня огромный комментарий получился из нескольких частей, прям, монолит какой-то...
Если основной посыл статьи — "думайте, прежде чем использовать микросервисы" — на 100% согласен.
Disclaimer: я не сторонник "пихать микросервисы везде", я за их умеренное использование там, где они уместны. На контрасте со статьёй дальнейшие слова могут показаться "фанатскими", однако, это не так.
Лично для меня основное удобство микросервисов в том, что в статье упомянуто как "Код небольшой и простой в обслуживании". Только в нашем случае (имею в виду часть проектов моей компании) я бы добавил "относительно" к "небольшой" и "простой"...
Когда кода реально много — появляются проблемы с тем, что, как ни старайся соблюдать границы внутри монолита, появляются "клубочки". Например, когда программисту проще смешать всё в одну кучу, потому что так удобнее решить конкретную задачу. А потом, с большой вероятностью, получить неожиданные сюрпризы из-за большой связанности кода.
Мы боремся с такими проблемами тем, что делаем явные границы, вынося их в API, которое уже контролируется и версионируется. Это создаёт дополнительные накладные расходы в разработке, спору нет. Зато дисциплинирует и позволяет надеяться на то, что, если поменяли только внутренности модуля, а мажорных изменений API нет, то поведение для вызывающего кода будет тем же.
А ещё, у каждого модуля свой жизненный цикл и вносить изменения в один модуль проще (в т.ч. с точки зрения тестирования). Конечно, до тех пор, пока не приходится делать мажорные изменения — тут уже надо решать, поддерживаем ли старую версию (и сколько старых версий) или всё настолько серьёзно, что лучше обновить все зависимости сразу.
Зато внутри модулей, особенно новых и не "устоявшихся", частично может быть подход "фигак-фигак и в продакшн", но он не распространяется как раковая опухоль на всё, а решение целиком работает приемлемо.
Почему я говорю про "модули" а не "микросервисы"? Потому что, строго говоря, те же самые преимущества можно получить и в рамках монолита (никто же не мешает сделать отдельные проекты и даже отдельные репозитории под модули). Но, на мой взгляд, сделать это сложнее, в основном — из-за возможности прямых вызовов.
Да, про прямые вызовы. У нас есть возможность сделать так, чтобы оба модуля были в одном процессе, но вызовы выглядят всё равно как внешние, через "прокси". И сериализацию параметров полезно оставить (чтобы, опять же, не прокрались лишние зависимости). Такой вот ".NET Remoting наоборот".
Возможно, мы какие-то нетипичные разработчики микросервисов и вообще (ужас!) — мы Docker не используем, хотя сервисы обычно распределены либо на несколько виртуалок, либо на несколько физических серверов.
В общем, из моего опыта (не буду называть что-то явно плюсом или минусом, не всё так просто):
микросервисы заставляют тратить больше усилий на этапе проектирования;
продуманный API — наше всё (мелкие исправления вносить несложно, а вот сильно переделывать — больно);
некоторые "минусы" микросервисов можно обойти, когда есть возможность править (или написать свой) код, отвечающий за инфраструктуру (внешние вызовы и т.п.);
не стоит ставить целью делать "мельчайшие" микросервисы, выше был правильный комментарий про Transaction Boundary и т.п.
В целом — скорее согласен с комментарием, но есть встречные комментарии.
В частности, есть правило, что микросервисы должны делиться так, чтобы не пересекать transaction boundary.
Это стараются обходить сагами и прочими ухищрениями, то есть правило не железобетонное. Но хорошее, да — всё-таки саги — это дополнительная сложность, дополнительная сложность заставляет меня грустить (поэтому обхожусь пока без саг).
В идеале никакой сервис не должен дергать другой сервис.
Ну, это слишком уж строгое ограничение. А лучший код — тот, который не написан? И то и другое звучит красиво, но работает редко.
Скажем так, если один микросервис изредка вызывает другой — не вижу проблемы. А вот если один микросервис постоянно вызывает другой — тут уже возникают вопросы, правильно ли выбрали границы.
Если у вас после проектирования получилось так, что пайплайн запроса состоит из пяти микросервисов, то это серьёзная ошибка, имхо.
Здесь согласен. Разве что, в качестве исключения могут быть инфраструктурные вызовы (положить в интеграционную шину, просигналить о необходимости отправки оповещения и т.п.). Но у всех по-разному это происходит — где-то для инфраструктуры библиотеки подключены, где-то — отдельные микросервисы.
Жалею, что статья не вышла раньше на две с половиной недели, как раз зуб удалил…
Странно, что хирург посоветовал поставить имплант в течение 3 месяцев и не сказал, что лучше сразу.
Правда, там была старая нижняя семёрка слева, с которой были проблемы ещё лет 25 назад, сейчас уже от зуба почти ничего и не осталось. С другой стороны нижнюю семёрку удалили тоже лет 25 назад, имплант тогда не поставил.
И вот вопрос — имеет ли смысл сейчас бежать и ставить имплант или уже не дёргаться и можно до июня подождать?
И, в принципе, насколько важно ставить имплант в текущей ситуации (с отсутствием правой семёрки проблем не испытываю)?
Видимо, на большинство продуктов лишь бегло посмотрели. А жаль — подумал, было — "наконец-то не только маркетинг". На примере Redmine, про который сказано:
Слабые стороны: устаревший интерфейс, некоторые функции спрятаны в очень неочевидных местах. Нет инструмента для отслеживания времени и активности пользователя по задачам. Система требует определенных навыков для установки на вашем собственном сервере. Также требуется время, чтобы сориентироваться в интерфейсах и понять назначение каждой функции.
Disclaimer: я не "евангелист" Redmine, даже не контрибьютор, просто им пользуюсь.
Давайте по пунктам.
Думаю, у большинства сколь-нибудь сложных продуктов некоторые функции спрятаны в очень неочевидных местах.
Инструмент для внесения времени есть (включается в настройках проекта). Если речь про всякие трекеры — не интересовался, может есть плагины (их море, кстати, только некоторые устаревшие).
Какой именно активности пользователя не хватает? Есть такая и такая. Или хочется мгновенного уведомления о комментариях или смене статуса задачи? Возможно, для кого-то важно (сам бы я отключил, если бы такое было и отключалось).
Про навыки для установки на собственном сервере — да, есть такое. Хотя есть хостинг и готовые образы для тех, кто не хочет или не может этим заниматься.
См. пункт (1). Если сравнивать с простыми продуктами с меньшим набором функций, то, конечно, они будут проще (чертовски логично).
В целом ощущения (по тому же HN и Twitter), что, как минимум, среди технарей больше поддерживающих JetBrains. Некоторые очень даже креативно поддерживают.
Другой вопрос, что не все бизнесмены и чиновники в технических вопросах прислушиваются к технарям. Хотя, казалось бы...
Держите более компактный вариант решения 3 задачи (план выполнения, думаю, аналогичный).
Может я не максимально понятно выразился. Для анализатора может и нет, но что мешает написать два анализатора и один настроить для билда, а другой для IDE? В документации есть, сам не пробовал, потому что не требовалось.
P.S. На случай, если новый редактор что-то сотворит со ссылкой, вот названия настроек оттуда:
Разве нельзя сделать две версии анализатора - один для билда, другой для live analysis (реюзая базовый код при этом)?
Тогда watch для билда совсем можно не делать (если только у вас не совсем что-то извращённое с ресурсами).
Подтверждаю, у меня семья тоже ест.
"В каком отделении репозиторий открывали, туда и приходите."
Вариант "не объясняй лишь злонамеренностью то, что вполне объясняется глупостью*" не идеален, но суть передаёт.
Что тоже немало для многих людей...
P.S. "*раздолбайством и т.п."
Всегда же так? Да? Ведь правда?
Первый способ будет ещё легче, если сразу поделить первое 365 на себя и потом сложить только 169 и 196.
Хранить пароли в облаке (чужом). Что могло пойти не так...
Уже релизнулся Rider 2021.3.
Немного странно видеть картинку в формате png размером 2.5 мегабайта в статье про оптимизацию...
В целом, присоединяюсь к большинству комментариев на тему "раньше было лучше". Особенно про счётчик непрочитанных комментариев.
По поводу "упасть при компиляции" - решается
nameof(a).P.S. Конечно, это не гарантирует, что не окажется поля с таким названием... Вероятность этого можно снизить с помощью StyleCop или чем-то вроде. Сам уже лет 10 пользуюсь для приватных полей подчёркиванием ("_name"), коллег тоже подсадил - все довольны.
Плюсану. Вы очень ёмко выразили основную мысль, которую я сам хотел донести в комментарии ниже. Но у меня огромный комментарий получился из нескольких частей, прям, монолит какой-то...
Если основной посыл статьи — "думайте, прежде чем использовать микросервисы" — на 100% согласен.
Disclaimer: я не сторонник "пихать микросервисы везде", я за их умеренное использование там, где они уместны. На контрасте со статьёй дальнейшие слова могут показаться "фанатскими", однако, это не так.
Лично для меня основное удобство микросервисов в том, что в статье упомянуто как "Код небольшой и простой в обслуживании". Только в нашем случае (имею в виду часть проектов моей компании) я бы добавил "относительно" к "небольшой" и "простой"...
Когда кода реально много — появляются проблемы с тем, что, как ни старайся соблюдать границы внутри монолита, появляются "клубочки". Например, когда программисту проще смешать всё в одну кучу, потому что так удобнее решить конкретную задачу. А потом, с большой вероятностью, получить неожиданные сюрпризы из-за большой связанности кода.
Мы боремся с такими проблемами тем, что делаем явные границы, вынося их в API, которое уже контролируется и версионируется. Это создаёт дополнительные накладные расходы в разработке, спору нет. Зато дисциплинирует и позволяет надеяться на то, что, если поменяли только внутренности модуля, а мажорных изменений API нет, то поведение для вызывающего кода будет тем же.
А ещё, у каждого модуля свой жизненный цикл и вносить изменения в один модуль проще (в т.ч. с точки зрения тестирования). Конечно, до тех пор, пока не приходится делать мажорные изменения — тут уже надо решать, поддерживаем ли старую версию (и сколько старых версий) или всё настолько серьёзно, что лучше обновить все зависимости сразу.
Зато внутри модулей, особенно новых и не "устоявшихся", частично может быть подход "фигак-фигак и в продакшн", но он не распространяется как раковая опухоль на всё, а решение целиком работает приемлемо.
Почему я говорю про "модули" а не "микросервисы"? Потому что, строго говоря, те же самые преимущества можно получить и в рамках монолита (никто же не мешает сделать отдельные проекты и даже отдельные репозитории под модули). Но, на мой взгляд, сделать это сложнее, в основном — из-за возможности прямых вызовов.
Да, про прямые вызовы. У нас есть возможность сделать так, чтобы оба модуля были в одном процессе, но вызовы выглядят всё равно как внешние, через "прокси". И сериализацию параметров полезно оставить (чтобы, опять же, не прокрались лишние зависимости). Такой вот ".NET Remoting наоборот".
Возможно, мы какие-то нетипичные разработчики микросервисов и вообще (ужас!) — мы Docker не используем, хотя сервисы обычно распределены либо на несколько виртуалок, либо на несколько физических серверов.
В общем, из моего опыта (не буду называть что-то явно плюсом или минусом, не всё так просто):
P.S. "спец-циалисты" — прям хорошо!
В целом — скорее согласен с комментарием, но есть встречные комментарии.
Это стараются обходить сагами и прочими ухищрениями, то есть правило не железобетонное. Но хорошее, да — всё-таки саги — это дополнительная сложность, дополнительная сложность заставляет меня грустить (поэтому обхожусь пока без саг).
Ну, это слишком уж строгое ограничение. А лучший код — тот, который не написан? И то и другое звучит красиво, но работает редко.
Скажем так, если один микросервис изредка вызывает другой — не вижу проблемы. А вот если один микросервис постоянно вызывает другой — тут уже возникают вопросы, правильно ли выбрали границы.
Здесь согласен. Разве что, в качестве исключения могут быть инфраструктурные вызовы (положить в интеграционную шину, просигналить о необходимости отправки оповещения и т.п.). Но у всех по-разному это происходит — где-то для инфраструктуры библиотеки подключены, где-то — отдельные микросервисы.
Читал "Дневники Киллербота", понравилось.
Жалею, что статья не вышла раньше на две с половиной недели, как раз зуб удалил…
Странно, что хирург посоветовал поставить имплант в течение 3 месяцев и не сказал, что лучше сразу.
Правда, там была старая нижняя семёрка слева, с которой были проблемы ещё лет 25 назад, сейчас уже от зуба почти ничего и не осталось. С другой стороны нижнюю семёрку удалили тоже лет 25 назад, имплант тогда не поставил.
И вот вопрос — имеет ли смысл сейчас бежать и ставить имплант или уже не дёргаться и можно до июня подождать?
И, в принципе, насколько важно ставить имплант в текущей ситуации (с отсутствием правой семёрки проблем не испытываю)?
Чёрт, я только после вашего комментария вспомнил, что коллеги давным-давно на одном из хакатонов запилили приложение для Android.
Вроде в комментах тут можно ссылки оставлять, тем более, что приложение бесплатное...
Redmine Time Management
Забыл, потому что сам не пользовался. Наверное, даже работает, если в свежем redmine кардинально эту часть API не поменяли.
Видимо, на большинство продуктов лишь бегло посмотрели. А жаль — подумал, было — "наконец-то не только маркетинг". На примере Redmine, про который сказано:
Disclaimer: я не "евангелист" Redmine, даже не контрибьютор, просто им пользуюсь.
Давайте по пунктам.
В целом ощущения (по тому же HN и Twitter), что, как минимум, среди технарей больше поддерживающих JetBrains. Некоторые очень даже креативно поддерживают.
Другой вопрос, что не все бизнесмены и чиновники в технических вопросах прислушиваются к технарям. Хотя, казалось бы...