ITnan

Все публикации Хабрахабр и Гиктаймс в одном месте
Выбран стиль: blue



Выбран тег динамики


  1. varanio
    /#10630258

    dry и kiss слишком простые, чтобы их описывать ). Расшифровка их аббревиатур является их сутью.
    Разве что про yagni можно рассказать дополнительно пару слов

  2. Sdima1357
    /#10630256

    Эти принципы сформировались на опыте программистов наступающих на известные грабли. По моему опыту принцип KISS тут главный и с высоким приоритетом. Все остальные можно и нужно нарушать если они противоречат этому принципу, правда лучше не торопиться и подумать ещё раз, возможно можно сделать ещё проще. Впрочем нет правил без исключений включая это. К сожалению даже умные учатся на своих ошибках, а на чужих не учится никто, впрочем возможно и в этом правиле есть исключения, но я не встречал (:…

  3. mayorovp
    /#10630254

    Наконец-то нашел где вы увидели эту конструкцию.

    Это не код страницы, это скриншот интерактивного инструмента для редактирования DOM (а не разметки — разметку уже давно распарсили и забыли!)

    Соответственно, все кавычки тут отображаются в декодированном виде просто потому что так удобнее человеку. В разметке же они были все экранированы.

    Перепутать кавычки которые границы атрибута с теми что внутри невозможно — они разных цветов :-)

  4. botyaslonim
    /#10630252

    Ещё один очень важный момент, про который все забывают: переплата в данном случае будет нечестной по отношению не только к Пете, но и к Васе. Если человек «переплачен» на входе, то ожидания от его работы у меня будут соответствующие. И тут тоже возникает множество проблем. Например, оценка работы Васи будет ниже, чем оценка работы Пети, а условный «карьерный рост» переплаченного сотрудника практически стопорится на то время, пока он не «догонит» уровень своей зарплаты. Да и потом «осадочек остаётся».

    — вот этот момент остался непонятным. Что «нечестного» по отношению к Васе, если это рынок труда, и он, как любой рынок, подвержен ценовым колебаниям? Почему карьерный рост «стопорится»? Карьера ведь по идее должна зависеть от умений человека, а не только от его стоимости для компании. Если следующий карьерная ступень на рынке труда стоит Х денег, то и Вася, скорее всего, запросит её, а не свою зарплату, помноженную на некий внутренний коэффициент, отражающий ваши представления о «справедливости». Не зря же в IT такая текучка кадров абсолютно во всех компаниях, за редкими исключениями! В чём «осадочек», если на этапе договорённости по зарплатам все приходят к согласию?

    По-моему, если бы все IT-гиганты публиковали свои реальные ставки, на рынке труда было бы гораздо спокойнее и светлее. Примерно одинаковый уровень квалификации оплачивался бы примерно одинаково. Вместо этого постоянные вихляния насчёт реального уровня оплаты (например, из Яндекса выбить цифры совершенно невозможно, только через знакомых, которые там работают) и сопутствующие эффекты, вроде «сегодня я узнал, что вы все 10 лет мне недоплачивали»

  5. rasswet
    /#10630248

    Яндекс он разный, на самом деле.

  6. System12
    /#10630246 / +1

    И тут я подумал, что очень много понаверчено принципов, которые произносятся с умным лицом и наморщенным лбом, хотя по сути там ничего сложного нет. Многие из них можно объяснить буквально одной фразой. Ну, может, абзацем текста или практическим примером. На пальцах, короче.

    Это справедливо для любой области знаний. Помнится был у меня один начальник, который требовал чтобы даже описание сложных вещей было написано понятным языком даже для уборщицы.

  7. Sinatr
    /#10630242

    В заголовке есть KISS, а в списке его нет. Плюс вы там советуете интерфейсы использовать в качестве параметров конструктора, дык это вроде как нужно делать, только если это нужно делать, не раньше. Там еще полно подобных принципов: YAGNI, DRY…

    Скорее всего озаглавить нужно было SOLID, раз уж Барбара в списке, но тогда труселя придется менять…

    Непонятно про дефолты. Ссылка на вики ничего не прояснила, какие-то json, принцип наименьшего удивления… может в таблице нужен третий столбец с маленьким «плохим» примером и «как надо»?

    Вы несколько раз пишете «класс должен делать что-то одно» или «меньше завязаны», а потом идет объяснение, но не для всех случаев, в результате некоторые принципы становятся не раскрытыми.

    А так вообще идея неплохая, намного проще держать в голове содержимое второго столбца, чем «сферическо-вакуумные» наименования, но не все у вас получилось. Когда именно я перестаю управлять собакой и начинаю управлять лапами?

  8. mayorovp
    /#10630238

    Во втором отладчик услужливо остановит исполнение там, где она произошла.

    Только если включен отлов First-chance exceptions, но эта настройка зачастую мешает нормальной отладке из-за исключений в библиотеках. В противном случае отладчик остановит исполнение только для тех исключений которые "утекают" из пользовательского кода.


    Применительно к вашему коду это означает, что исключение в SendEmail или ChangeUserName поймано отладчиком не будет ни в каком из двух вариантов (а ведь именно эти исключения как правило наиболее интересны — валидация-то зачастую слишком очевидна чтобы ее отлаживать, да и сообщения об ошибках там самые понятные).


    По мне, так лучше всего вот так делать:


    [HandleErrors]
    public IActionResult Post(ChangeUserNameCommand command)
    {
          var res = command.Validate();
          if (res.IsFaulted) return Fault(res);
    
          return SendEmail(ChangeUserName(command));
    }

    То есть ошибки валидации обрабатываем как возвращаемое значение (это необходимо хотя бы потому что их может быть много, а не одно) — а ошибки обработки запроса надо делать уже исключениями, причем с обязательным утеканием исключений в системный код перед перехватом (тут может помочь [DebuggerNonUserCode] если используемый фреймворк не позволяет обрабатывать исключения какими-нибудь фильтрами).

  9. MonkAlex
    /#10630236

    1. И в чём проблема? У меня спокойно работает на Моно в Линукс-минте, ни разу не под управлением интел. И давно уж.
    2. ДотНет просто тяжело защитить. Большинство самописных «защит» какой нибудь dnSpy спокойно обойдет. При чем тут Paint.NET — не понял, он же редактор картинкок, зачем ограничивающая песочница то? Увести фоточки?

  10. Victor_koly
    /#10564021

    Плутоний-239 делится альфа-частицами? Речь о кюрии-243 с вероятностью SF до 4 миллионных процента?
    Я конечно подозреваю, что там при подходящей энергии нейтрона вероятность спонтанного деления не миллионные доли процента выходит, а куда больше.
    P.S. Но видимо с вероятностью до 99.71% альфа-частица буквально пролетает через ядро плутония-239.
    P.P.S. Никакая геометрия не поможет при размножении 0.94. Если поддержите размножение 0.945 в течении 1000 периодов пролета нейтрона — хорошо будет. еслтесвенно — в объеме критической массы, а не 239 грамм плутония.