Мне понравилась идея с <ТТ> — в отличие от Bind(typeof(IBox< >)).To(typeof(MyBox<>)) здесь компилятор сможет проверить, что MyBox<T> реализует IBox<T>, если я правильно понял. Определение циклических зависимостей и прочих ошибок на этапе компиляции, а не при запуске, как в классических DI фреймворках, тоже полезная фишка.
Но что касается производительности, мне действительно трудно представить кейс, когда resolve ощутимо сказывается на перфомансе. Коллега пару лет назад тестировал несколько библиотек (Ninject, Autofac, MS DI, если правильно помню) и пришёл к выводу, что разрешение даже огромного графа зависимостей занимает довольно ничтожное время, сравнение по этому критерию не имеет смысла. Если у вас есть данные в подтверждение противоположной точки зрения, будет любопытно взглянуть.
Тут тоже автор не вполне точен, речь не про "её детей", а про детей вообще, которые шумные не прямо сейчас, а в принципе. Отсюда present simple и отсутствие согласования времён (как в вашем варианте). Так что на мой взгляд, более точный перевод "я убедил её, дети — это шумно"
Вы так уверенно говорите, что оно не тормозило на 486-м, как будто пробовали выполнить на тысяче значков. Не исключено, что алгоритм писался тяп-ляп с осознанием того, что у пользователя не поместится больше сотни значков на столе, и кому какое дело, какая сложность у этого алгоритма, и с тех пор просуществовал без изменений.
Если вы, зная в точности программу полёта знаете, что ровно через 11 минут аппарат будет приземляться, вы можете отправить управляющее воздействие — ну, скажем, разложить опоры, которые забыли заложить в программу. И этот сигнал успеет дойти, опоры будут разложены, аппарат успешно сядет, отношения причинности нарушены не будут. А вот если мы получили сигнал "нахожусь в ста метрах над поверхностью" — по вашей терминологии вот прямо сейчас он там находится — но посылать сигналы уже поздно, даже если бы у нас был способ послать его мгновенно, потому что фактически находился он там 11 минут назад, и раскладывать опоры уже некому.
Ещё частенько употребляются gorgeous, amazing, perfect.
А наш PO часто использует слово outstanding в значении "оставшийся нерассмотренным" (outstanding questions, outstanding issue) — раньше не встречал такого значения, было интересно узнать.
Эта мнемоника может сыграть злую шутку; если в самом начале изучения языка запомнится неверно, переучить мозг будет очень трудно. Итс трулай хот ин джулай? Итс трули хот ин джули?
Про lose и loose — если знать, что это два разных по смыслу слова, ошибиться будет чуточку труднее.
Легко, в тех случаях, когда инициативный джун начинает изобретать велосипеды и тонет в их отладке, а сеньор знает, какую готовую библиотеку заиспользовать. Сколько уже написано самодельных очередей, аутентификаций, шаблонизаторов, etc., etc.
Поддержу. В xml есть мощнейший механизм описания схемы данных; подключив правильную схему можно практически на 100% защититься от того, что конфиг окажется некорректным — IDE подскажет, что куда писать и подсветит все ошибки.
Но нет, давайте переходить на JSON, а корректность структуры проверять по документации… Окей, завезли JSON schema, с грехом пополам вроде заработало, немного приблизившись к xml+xsd.
В топку! Давайте все переходить на YML.
// не то чтобы я был большим фанатом XML, просто ситуация забавляет
Увы, но вот как раз-таки этому не учат. Это искусство, которое постигают на практике. Но тут дело такое — каждый исполнитель может свести данные по-своему, и уровень мастерства определяется степенью правдоподобности: углы у зданий прямые, горизонтали лежат ровненько и не пересекаются и т. д. Здесь нужен тренированный глаз и практика, но какой-то фундаментальной сложности нет. А каталоги координат наоборот — на вид цифры и цифры, что в одной системе координат, что в другой, но поскольку вся топосъемка опирается на них, то маленькая ошибка в каталоге может иметь очень большие последствия потом, когда результаты съемки не будут сходиться.
Вот так и знал, что кто-нибудь прицепится к словам. По-моему, из контекста с высокой долей достоверности следовало, что автор комментария общался именно с прикладниками.
Да нет, в прикладной геодезии действительно не так много сложного, и практикум по топографии студенты сдают уже после первого курса. Там не требуется ничего такого, с чем программист или, шире, инженер, не сможет разобраться. Помню, вел переписку по работе с субподрядчиками, пытаясь доказать, что у них ошибка в каталоге координат. На том конце провода уже скатились до доводов вида "я 30 лет в геодезии!" (дословно), но еще через пару итераций признали ошибку и выслали исправленный вариант.
PS это не отменяет того, что высшая геодезия — это весьма сложная наука, но ей и занимаются совершенно другие люди, не "геодезисты в офисе".
В случае с монадами так не получится. Если взялся их использовать в одном месте, то дальше приходится распространять их по всему коду, даже в тех местах, где обработка ошибок не предполагается. Мне такой подход именно по этой причине не зашел.
Ну, вы конечно утрируете, но кое-какое здравое зерно в этом есть. Вот работал я годами на VS, и меня все устраивало, попробовать тот же Райдер не тянуло, да и некогда было, при том, что у меня даже лицензия была на All products pack. А вот оказался бы рядом кто-то, кто сказал бы "Устали запускать две копии студии, чтобы отладить две программы одновременно? Попробуйте нашу МЭЙДЖИК IDE 2020...." — я бы может созрел попробовать гораздо раньше. Понятно, что для разработчиков форма подачи должна отличаться от ЦА магазина на диване, но идея в том, что потенциальный клиент может и не осознавать своей боли, и если вы можете ее устранить, надо ему об этом рассказать.
С другой стороны, такой пример попахивает не очень хорошо, и если анализатор подсвечивает этот code smell, в этом тоже есть определенная польза, кто-то может захотеть отрефакторить его более очевидным способом.
Потому что кто-то может удалить проверку, которая выглядит избыточной, и без подсказки анализатора.
А ведь есть еще антоним энтропии — негэнтропия, мера упорядоченности. И вот от него мне взрывает мозг еще сильнее. Почему "упорядоченность" названа как "отрицательный беспорядок"? Зато можно придумать множество столь же чумовых слов. "Неглодырь" для обозначения трудолюбивого человека. "Негтупица" для умного. Негбольной. Негмертвый…
На миллиарде да, разница небольшая и легко может быть полностью нивелирована разницей в сложности единичных операций. Но на триллионе разница почти в 16 раз. А на квадриллионе — в 256.
О том и речь, что на практике такие количества нечасто обрабатываются, мягко говоря.
Мне понравилась идея с
<ТТ>— в отличие отBind(typeof(IBox< >)).To(typeof(MyBox<>))здесь компилятор сможет проверить, чтоMyBox<T>реализуетIBox<T>, если я правильно понял. Определение циклических зависимостей и прочих ошибок на этапе компиляции, а не при запуске, как в классических DI фреймворках, тоже полезная фишка.Но что касается производительности, мне действительно трудно представить кейс, когда resolve ощутимо сказывается на перфомансе. Коллега пару лет назад тестировал несколько библиотек (Ninject, Autofac, MS DI, если правильно помню) и пришёл к выводу, что разрешение даже огромного графа зависимостей занимает довольно ничтожное время, сравнение по этому критерию не имеет смысла. Если у вас есть данные в подтверждение противоположной точки зрения, будет любопытно взглянуть.
Тут тоже автор не вполне точен, речь не про "её детей", а про детей вообще, которые шумные не прямо сейчас, а в принципе. Отсюда present simple и отсутствие согласования времён (как в вашем варианте). Так что на мой взгляд, более точный перевод "я убедил её, дети — это шумно"
Вы так уверенно говорите, что оно не тормозило на 486-м, как будто пробовали выполнить на тысяче значков. Не исключено, что алгоритм писался тяп-ляп с осознанием того, что у пользователя не поместится больше сотни значков на столе, и кому какое дело, какая сложность у этого алгоритма, и с тех пор просуществовал без изменений.
Если вы, зная в точности программу полёта знаете, что ровно через 11 минут аппарат будет приземляться, вы можете отправить управляющее воздействие — ну, скажем, разложить опоры, которые забыли заложить в программу. И этот сигнал успеет дойти, опоры будут разложены, аппарат успешно сядет, отношения причинности нарушены не будут. А вот если мы получили сигнал "нахожусь в ста метрах над поверхностью" — по вашей терминологии вот прямо сейчас он там находится — но посылать сигналы уже поздно, даже если бы у нас был способ послать его мгновенно, потому что фактически находился он там 11 минут назад, и раскладывать опоры уже некому.
Ещё частенько употребляются gorgeous, amazing, perfect.
А наш PO часто использует слово outstanding в значении "оставшийся нерассмотренным" (outstanding questions, outstanding issue) — раньше не встречал такого значения, было интересно узнать.
Ещё в русском ударение может ставиться по совершенно непостижимым правилам. Золото, болото, долото — логике не поддается.
Чисто из спортивного интереса: любопытно, какое место по производительности заняли бы switch-expressions из девятого C#.
Эта мнемоника может сыграть злую шутку; если в самом начале изучения языка запомнится неверно, переучить мозг будет очень трудно. Итс трулай хот ин джулай? Итс трули хот ин джули?
Про lose и loose — если знать, что это два разных по смыслу слова, ошибиться будет чуточку труднее.
Увидев название в ленте, решил, что nmivan возобновил "корпоративную" серию, ан нет, ошибочка вышла.
Легко, в тех случаях, когда инициативный джун начинает изобретать велосипеды и тонет в их отладке, а сеньор знает, какую готовую библиотеку заиспользовать. Сколько уже написано самодельных очередей, аутентификаций, шаблонизаторов, etc., etc.
Поддержу. В xml есть мощнейший механизм описания схемы данных; подключив правильную схему можно практически на 100% защититься от того, что конфиг окажется некорректным — IDE подскажет, что куда писать и подсветит все ошибки.
Но нет, давайте переходить на JSON, а корректность структуры проверять по документации… Окей, завезли JSON schema, с грехом пополам вроде заработало, немного приблизившись к xml+xsd.
В топку! Давайте все переходить на YML.
// не то чтобы я был большим фанатом XML, просто ситуация забавляет
Только two-thirds это не "в два-три раза", а "две трети от". Но это уже ошибка в пределах одного порядка, а не 10, как в статье :)
Увы, но вот как раз-таки этому не учат. Это искусство, которое постигают на практике. Но тут дело такое — каждый исполнитель может свести данные по-своему, и уровень мастерства определяется степенью правдоподобности: углы у зданий прямые, горизонтали лежат ровненько и не пересекаются и т. д. Здесь нужен тренированный глаз и практика, но какой-то фундаментальной сложности нет. А каталоги координат наоборот — на вид цифры и цифры, что в одной системе координат, что в другой, но поскольку вся топосъемка опирается на них, то маленькая ошибка в каталоге может иметь очень большие последствия потом, когда результаты съемки не будут сходиться.
Вот так и знал, что кто-нибудь прицепится к словам. По-моему, из контекста с высокой долей достоверности следовало, что автор комментария общался именно с прикладниками.
Да нет, в прикладной геодезии действительно не так много сложного, и практикум по топографии студенты сдают уже после первого курса. Там не требуется ничего такого, с чем программист или, шире, инженер, не сможет разобраться. Помню, вел переписку по работе с субподрядчиками, пытаясь доказать, что у них ошибка в каталоге координат. На том конце провода уже скатились до доводов вида "я 30 лет в геодезии!" (дословно), но еще через пару итераций признали ошибку и выслали исправленный вариант.
PS это не отменяет того, что высшая геодезия — это весьма сложная наука, но ей и занимаются совершенно другие люди, не "геодезисты в офисе".
В случае с монадами так не получится. Если взялся их использовать в одном месте, то дальше приходится распространять их по всему коду, даже в тех местах, где обработка ошибок не предполагается. Мне такой подход именно по этой причине не зашел.
Ну, вы конечно утрируете, но кое-какое здравое зерно в этом есть. Вот работал я годами на VS, и меня все устраивало, попробовать тот же Райдер не тянуло, да и некогда было, при том, что у меня даже лицензия была на All products pack. А вот оказался бы рядом кто-то, кто сказал бы "Устали запускать две копии студии, чтобы отладить две программы одновременно? Попробуйте нашу МЭЙДЖИК IDE 2020...." — я бы может созрел попробовать гораздо раньше. Понятно, что для разработчиков форма подачи должна отличаться от ЦА магазина на диване, но идея в том, что потенциальный клиент может и не осознавать своей боли, и если вы можете ее устранить, надо ему об этом рассказать.
С другой стороны, такой пример попахивает не очень хорошо, и если анализатор подсвечивает этот code smell, в этом тоже есть определенная польза, кто-то может захотеть отрефакторить его более очевидным способом.
Потому что кто-то может удалить проверку, которая выглядит избыточной, и без подсказки анализатора.
А ведь есть еще антоним энтропии — негэнтропия, мера упорядоченности. И вот от него мне взрывает мозг еще сильнее. Почему "упорядоченность" названа как "отрицательный беспорядок"? Зато можно придумать множество столь же чумовых слов. "Неглодырь" для обозначения трудолюбивого человека. "Негтупица" для умного. Негбольной. Негмертвый…
На миллиарде да, разница небольшая и легко может быть полностью нивелирована разницей в сложности единичных операций. Но на триллионе разница почти в 16 раз. А на квадриллионе — в 256.
О том и речь, что на практике такие количества нечасто обрабатываются, мягко говоря.