Мне кажется, KPI работают в тех областях, где операции однообразные, имеющие чёткий алгоритм решения без фазы творчества, то бишь "на конвейер". Я надо сказать, мало работал в таких сферах, поэтому в айти как-то действительно непросто придумать объективную систему KPI.
Мне любопытно, вот если есть два работника, у обоих позиция в штатном расписании называется одинаково, должны ли быть у них одинаковые KPI?
Допустим, давайте не будем обсуждать русские реалии и ситуацию "сын начальника", а возьмём сферическую зарубежную компанию. Как у них делают по уму? Для негра одни KPI, для лиц нетрадиционной ориентации другие, для белого гетеросексуального мужчины третьи?
Вопрос не для розжигу, я сам понимаю, что легко скатиться в малопродуктивное обсуждение, поэтому заранее большое спасибо, кто серьёзно отнесётся к вопросу и удержится при ответе в деловом ключе.
Несмотря на то, что статья (и вся серия) это якобы про бизнес-логику по факту статья о работе с базой. И я не чтобы прям топлю за DDD, в котором рисуешь домен, который ничего не знает о Persistence или принижаю значимость базы данных (подавляющее большинство enterprise вокруг БД крутится, чаще всего одной из тройки реляционных), просто глянул в комментарии к прошлой статье о том, что обёртка есть только для одной БД и даже не особо умеет plain sql типа как в Dapper.
И вся логика начинается с фразы From<Db> — ну это понятно, что вроде как это "канал" и вроде как можно иные каналы описать… но по факту это просто иная разновидность EF, причём там уже под разные SQL базы есть неплохая кодовая база (хотя то, как реализована mysql мне лично не особо нравится). И она может быть в чём-то лучше, чем EF, в чём-то просто "иначе" ("привыкнешь")
А допустим, если сказать "очереди СМЭВ" — и это уже будет кагбэ за рамками статьи? Тоже вроде как "логика".
Ты всё равно не будешь укладываться в дедлайн, выше же было об этом. Как скоро выкинут тебя на улицу — вопрос неоднозначный, от фирмы зависит, но на твоё место действительно полно желающих. Тут ещё теорию игр можно подтянуть, посмотреть наиболее эффективные стратегии для обоих сторон.
С одной стороны прикольно типа, с другой стороны мешает читать. Представляю как бы это всё на старославянском было бы написано — ещё сложнее читать, хотя вроде всё знакомо и понятно.
Ну то есть этот стиль он был использован в итоге как выразительное средство для того, чтобы что? Непонятно.
И да, ожидалась развязка интриги в духе одного кольца над всеми, любопытно было как автор извернётся, но нет, так и повисла обломно незакрытым гештальтом.
Разберем, как выявлять признаки обмана в речи и невербальных проявлениях
Пол Экман based? Я могу из его книг сделать краткую выжимку в одно предложение: однозначных признаков лжи нет.
Текущая статья слишком краткая (согласен с предыдущим оратором), при этом с одной стороны мало упомянута механика памяти (например не могу понять, почему ни словом не упомянута Элизабет Лофтус с её экспериментами), а с другой стороны нарушается обещание статьи: не просто рассказ "как это работает", а "Разберем, как выявлять".
Поэтому совершенно не стоило дробить статью на такие краткие ничего не значащие кусочки: формат твитерра — в твиттер, хабр же для глубоких статей. Ну вот например соседняя, просто сравните: https://habr.com/en/post/518716/
Жаль в статье нет оценки, сколько понадобится дисков под этот массив информации. Вот например, в России опсосы за год не могут хранить копию трафика (привет Яровой) — столько дисков нет ещё на всей планете, а за 20-75 лет?? Интересно, как у них вопли по этому поводу уже были? Ведь это же другой вектор атаки на систему, помимо "вы плюёте на прайваси": это же деньги налогоплательщиков, кто-то же должен оплатить?
Хороший вариант, особенно когда есть понимание, что ничего больше в блоках добавляться не будет. Версия которую я предложил — та что решарпер подсказывает с включенной Redundand else
Можете привести пример чего-то такого нетривиального, не является дурным примитивом? У меня очень часто идёт работа с двумя репозиториями, ежедневно пользуюсь rebase но никак не могу взять в толк о чём идёт речь, всё достаточно просто и понятно.
Ну или хотя бы сформулируйте проблему, по которой есть только дурные примитивы в оффруководствах.
— Абрам, где ты достал себе такой костюм?
— В Париже.
— А это далеко от Бердичева?
— Ну, примерно, две тысячи километров будет.
— Подумать только! Такая глушь, а так шьют хорошо!
Автор статьи живёт в какой-то паралельной вселенной. Как только клиент поставит типовой сайт на битрикс — всё хорошо, но каждый шаг чуть в сторону от коробки — это просто попоболь, когда ты вдруг узнаёшь что там под капотом у этой коробки.
Про это ни слова, ни слова про то, как многие годы продукт не развивался для программистов, просто добавляли новые свистульки для начальства.
Я тоже остановился примерно там же, но вопрос сформулировал ещё проще: что это, если не "автор открыл для себя декомпозицию". Мы просто делим сложный объект на более простые. Не? Или я что-то не уловил?
Статья по факту из двух отдельных состоит: собственно полезные настройки EF (ну — те, которые автор посчитал таковыми) и как переписывать sql в linq.
В первой части стиль конечно просто полный улёт. С одной стороны это стиль такого прожженого профи, который свысока объясняет как правильно, с другой стороны если это был сборник советов, как правильно для тех, кто ещё в маленьких штанишках бегает — то рассказано настолько кратко, что они ничего не поймут. Просто обозначили, что есть IEntityTypeConfiguration — но остальное новичку всё равно придётся догугливать.
Вторая часть была интересна, но опять же написана не для новичков. Мало примеров! Всё как-то абстрактно написано, а можно было бы сделать более наглядно.
Статья не для новичков однозначно, хотя так и позиционируется.
Воздержался от минусов, тут уже вон два вижу, но однозначно планировал влепить.
Мне кажется, KPI работают в тех областях, где операции однообразные, имеющие чёткий алгоритм решения без фазы творчества, то бишь "на конвейер". Я надо сказать, мало работал в таких сферах, поэтому в айти как-то действительно непросто придумать объективную систему KPI.
Мне любопытно, вот если есть два работника, у обоих позиция в штатном расписании называется одинаково, должны ли быть у них одинаковые KPI?
Допустим, давайте не будем обсуждать русские реалии и ситуацию "сын начальника", а возьмём сферическую зарубежную компанию. Как у них делают по уму? Для негра одни KPI, для лиц нетрадиционной ориентации другие, для белого гетеросексуального мужчины третьи?
Вопрос не для розжигу, я сам понимаю, что легко скатиться в малопродуктивное обсуждение, поэтому заранее большое спасибо, кто серьёзно отнесётся к вопросу и удержится при ответе в деловом ключе.
Несмотря на то, что статья (и вся серия) это якобы про бизнес-логику по факту статья о работе с базой. И я не чтобы прям топлю за DDD, в котором рисуешь домен, который ничего не знает о Persistence или принижаю значимость базы данных (подавляющее большинство enterprise вокруг БД крутится, чаще всего одной из тройки реляционных), просто глянул в комментарии к прошлой статье о том, что обёртка есть только для одной БД и даже не особо умеет plain sql типа как в Dapper.
И вся логика начинается с фразы
From<Db>— ну это понятно, что вроде как это "канал" и вроде как можно иные каналы описать… но по факту это просто иная разновидность EF, причём там уже под разные SQL базы есть неплохая кодовая база (хотя то, как реализована mysql мне лично не особо нравится). И она может быть в чём-то лучше, чем EF, в чём-то просто "иначе" ("привыкнешь")А допустим, если сказать "очереди СМЭВ" — и это уже будет кагбэ за рамками статьи? Тоже вроде как "логика".
Ты всё равно не будешь укладываться в дедлайн, выше же было об этом. Как скоро выкинут тебя на улицу — вопрос неоднозначный, от фирмы зависит, но на твоё место действительно полно желающих. Тут ещё теорию игр можно подтянуть, посмотреть наиболее эффективные стратегии для обоих сторон.
Здраво звучит, спасибо за конкретику.
С одной стороны прикольно типа, с другой стороны мешает читать. Представляю как бы это всё на старославянском было бы написано — ещё сложнее читать, хотя вроде всё знакомо и понятно.
Ну то есть этот стиль он был использован в итоге как выразительное средство для того, чтобы что? Непонятно.
И да, ожидалась развязка интриги в духе одного кольца над всеми, любопытно было как автор извернётся, но нет, так и повисла
обломнонезакрытым гештальтом.Пол Экман based? Я могу из его книг сделать краткую выжимку в одно предложение: однозначных признаков лжи нет.
Текущая статья слишком краткая (согласен с предыдущим оратором), при этом с одной стороны мало упомянута механика памяти (например не могу понять, почему ни словом не упомянута Элизабет Лофтус с её экспериментами), а с другой стороны нарушается обещание статьи: не просто рассказ "как это работает", а "Разберем, как выявлять".
Поэтому совершенно не стоило дробить статью на такие краткие ничего не значащие кусочки: формат твитерра — в твиттер, хабр же для глубоких статей. Ну вот например соседняя, просто сравните: https://habr.com/en/post/518716/
Редко стал заходить в такие общие статьи ибо информации много и большинство просто шлак, но тут неожиданно наткнулся и понравилось.
Жаль в статье нет оценки, сколько понадобится дисков под этот массив информации. Вот например, в России опсосы за год не могут хранить копию трафика (привет Яровой) — столько дисков нет ещё на всей планете, а за 20-75 лет?? Интересно, как у них вопли по этому поводу уже были? Ведь это же другой вектор атаки на систему, помимо "вы плюёте на прайваси": это же деньги налогоплательщиков, кто-то же должен оплатить?
Я думаю — просто магия ровных цифр, так я видел и 100 и 120. Много уже проектов в кодстайле прописали 100 символов, мммм… навскидку: https://github.com/airbnb/javascript
Хороший вариант, особенно когда есть понимание, что ничего больше в блоках добавляться не будет. Версия которую я предложил — та что решарпер подсказывает с включенной Redundand else
Redundand else детектед:
Лучше, т.к. экономит горизонтальное пространство для блока else:
Один хоткей в решарпере, он по дефолту именно так и выравнивает linq по точкам.
То же самое и здесь: тот же хоткей, который просто въедается в автоматизм.
Время ценно, тратить время разработчиков на то, чтобы вручную форматировать код — в 2020 году это нонсенс.
Можете привести пример чего-то такого нетривиального, не является дурным примитивом? У меня очень часто идёт работа с двумя репозиториями, ежедневно пользуюсь rebase но никак не могу взять в толк о чём идёт речь, всё достаточно просто и понятно.
Ну или хотя бы сформулируйте проблему, по которой есть только дурные примитивы в оффруководствах.
Хм, всё-таки история нетривиальна именно попаданием с первого раза, обычно ~ где-то из сотни интервью до офера штук пять доходит.
Вы прям как в том анекдоте:
— Абрам, где ты достал себе такой костюм?
— В Париже.
— А это далеко от Бердичева?
— Ну, примерно, две тысячи километров будет.
— Подумать только! Такая глушь, а так шьют хорошо!
Первый час после операции тоже не сахар, полыхает огнём.
Автор статьи живёт в какой-то паралельной вселенной. Как только клиент поставит типовой сайт на битрикс — всё хорошо, но каждый шаг чуть в сторону от коробки — это просто попоболь, когда ты вдруг узнаёшь что там под капотом у этой коробки.
Про это ни слова, ни слова про то, как многие годы продукт не развивался для программистов, просто добавляли новые свистульки для начальства.
Я тоже остановился примерно там же, но вопрос сформулировал ещё проще: что это, если не "автор открыл для себя декомпозицию". Мы просто делим сложный объект на более простые. Не? Или я что-то не уловил?
Статья по факту из двух отдельных состоит: собственно полезные настройки EF (ну — те, которые автор посчитал таковыми) и как переписывать sql в linq.
В первой части стиль конечно просто полный улёт. С одной стороны это стиль такого прожженого профи, который свысока объясняет как правильно, с другой стороны если это был сборник советов, как правильно для тех, кто ещё в маленьких штанишках бегает — то рассказано настолько кратко, что они ничего не поймут. Просто обозначили, что есть IEntityTypeConfiguration — но остальное новичку всё равно придётся догугливать.
Вторая часть была интересна, но опять же написана не для новичков. Мало примеров! Всё как-то абстрактно написано, а можно было бы сделать более наглядно.
Статья не для новичков однозначно, хотя так и позиционируется.
Воздержался от минусов, тут уже вон два вижу, но однозначно планировал влепить.