Чем try/catch, в качестве альтернативы которому был приведён этот код.
Т.е. вызов метода Err() у результата void-метода Set(), по мнению, vGrabko99, меньше "запутывает структуру кода" и не "смешивает обработку ошибок с нормальной обработкой".
Это тормоза, которые в принципе невозможно победить. Студия обвешивается свистоперделками дополнительным функционалом, который дёргается на каждый чих, что-то крутится в фоне, что-то при открытии проекта… В результате отзывчивость UI просто катастрофически проседает (это у меня рабочий i7+32gb+ssd). Я не буду сейчас вспоминать по адский ад, который творился в R#8 (это было давно и с тех пор вы, конечно, многое поменяли/поправили), но в компании есть лицензии, так что я по мере выхода новых версий ставлю их «пощупать» и через неделю сношу с недоумением. Выглядит коряво (ну совсем неродные интерфейсные элементы); редактор кода (в котором проводишь 95% времени) начинает ощутимо тормозить; функционал либо дублирует уже (за эти годы) появившийся в VS из коробки, либо легко заменяется небольшим набором экстеншнов, которые бесплатны и работают в разы быстрее.
Ну т.е. я честно каждый раз делаю попытку понять, почему вокруг каждый второй говорит "без решарпера ваще не могу работать" и не нахожу ответа.
Для меня важно, чтоб не тормозило открытие файлов, чтоб табы переключались быстро, чтоб всякие подсказки типа IntelliSense выскакивали без задержек в секунду и более… Т.е. стабильность и плавность постоянно используемого функционала важнее, чем странный комбайн, который после установки требует несколько дней только на то, чтоб отключить все ненужные функции, выскакивающие где не надо. И ещё и денег за это просит.
Так что мой выбор "не пользоваться".
А вот где, кому и что мне говорить — не вам мне указывать.
Если честно — фиговенькая попытка. Убедительных доводов «в защиту» в статье не особо увидел (ну правда, хватит уже тыкать мне в лицо этим списком компаний), а вот в унылые вялые оправдания статья скатилась бодренько. "Ну даа, есть проблема… ну даа, печально известный баг… нуда..."
Итоговое впечатление "всё равно его не брошу, потому что он хороший". А я не выберу MySQL, как хранилище данных, какие бы критерии у проекта ни были — потому что вижу, что потенциального геморроя можно словить на порядок больше, чем… А даже преимуществ-то не вижу. Что, первичная простота развёртывания? Смешно.
mbc это опечатка mvc. С телефона писал и когда заметил — уже исправить нельзя было.
И что такого убогого и ущербного в webforms
Ну, начнём со ViewState и всего с ним связанного. А с ним связано всё.
Продолжим костылями типа UpdatePanel, мракобесной цепочки HttpModule/HttpFilter/HttpHandler. А на закуску DataBinding в контексте событийной модели — вот там самные прекрасные танцы.
Webforms дает более-менее формальное разделение между программированием и версткой, удачно разделяя бизнес логику и визуальное представление
Агада. Прям учит, как надо разделять их. Контролы, на события которых можно подписываться прям в шаблоне, там же рядом прописывая Css-свойства и вставляя туда же биндинги на DataSource…
Возможно, вас память обманывает, скрывая плохое. Но изначально в ASP.NET не было даже precompiled web application и не было code behind. Т.е. весь код, шаблон и css были в одном файле, разделённые самым прекрасным блоком на свете:
<script runat="server" >
Т.е. то, что вы сейчас называете WebForms — это результат тринадцати лет непрерывных попыток костылями и подпорками продержать всё это мракобесие на плаву.
Учитывая, что первый MVC вышел в 2009м году и уже тогда был просто божественным откровением (т.е. ещё шесть лет назад всем было понятно, насколько WebForms несостоятелен) — то ныть сейчас про накопленный багаж "наработок, опыта, сторонних компонентов" довольно самокритично.
Как .net-разработчик, я только всячески приветствую как можно скорейшее закапывание WebForms в землю. Эта «технология» изначально была создана только для упрощения процесса перетаскивания всех этих VisualBasic/Delphi разрабов в веб. И изначально убога, ущербна и изобилует такими кошмарными костылями, что туда ей и дорога.
Я могу понять вой тех «несчастных», которые сделали ставку на то, чтоб доить разрабов, которые упёрлись в потолок, возникший на пересечении ограничений aps.net из коробки и собственных возможностей… Но что поделаешь. Если не успели поймать ветер mbc, то всё дальнейшее развитие вам тоже будет болезненно.
Оно, конечно, так. В теории. Но:
1. Pre-commit hook это та же клиентская фигня, что и TFVC checkin policy. Тот ещё мрак всем машины настраивать, раскладывая StyleCop и конфиги. А потом ещё обновления велосипедить.
2. Да, бывает ещё серверный pre-receive hook, но если используется git, который в составе TFS, то о нём можно только мечтать. ISubscriber в этом случае — единственный способ.
Есть ещё вариант gated -конфигурации, когда все коммитят в git, который на самом деле проксирует это в другой git и уже на нём (первом) понастроить все эти pre-commit hook… Но это для очень сильных духом.
А «этично» ли запускать фонограмму на концерте? Мне кажется, шоубиз давно ответил на этот вопрос. Есть исполнители, на фонограмму которых люди ползут толпами, тряся дензнаками. А есть, где засмеют за одну мысль о таком. Так что этики тут нет. Только спрос и предложение.
bing — на два года. ну или зависит от акции, возможно. у меня сейчас 140 Gb (15 бесплатных, 15 за camera roll, 10 за loyalty и 100 за bing rewards до 02/10/2017).
а вообще есть office365, который за personal (69$/y) даёт на PC пакет Office и 1Tb места к нему (а за Home, 99$/y — Office на до 5ти устройств и по 1Tb на 5 аккаунтов).
Эт само собой. Есть, например, StyleCopAnalyzers, который пока в глубокой бете. Есть другие разные штуки.
Но суть не в этом. Статейка больше про MSBuild, чем про StyleCop.
… А пока вы практиковались в занимательной арифметике чуть менее амбициозный джуниор тихо кивнул на «команду свыше» и молча начал пилить на скалке.
Есть такая тема, что когда отдел большой, то со временем «неудобные» вопросы начинают уходить к тихим сговорчивым лидам.
Т.е. вызов метода Err() у результата void-метода Set(), по мнению, vGrabko99, меньше "запутывает структуру кода" и не "смешивает обработку ошибок с нормальной обработкой".
свистоперделкамидополнительным функционалом, который дёргается на каждый чих, что-то крутится в фоне, что-то при открытии проекта… В результате отзывчивость UI просто катастрофически проседает (это у меня рабочий i7+32gb+ssd). Я не буду сейчас вспоминать по адский ад, который творился в R#8 (это было давно и с тех пор вы, конечно, многое поменяли/поправили), но в компании есть лицензии, так что я по мере выхода новых версий ставлю их «пощупать» и через неделю сношу с недоумением. Выглядит коряво (ну совсем неродные интерфейсные элементы); редактор кода (в котором проводишь 95% времени) начинает ощутимо тормозить; функционал либо дублирует уже (за эти годы) появившийся в VS из коробки, либо легко заменяется небольшим набором экстеншнов, которые бесплатны и работают в разы быстрее.Ну т.е. я честно каждый раз делаю попытку понять, почему вокруг каждый второй говорит "без решарпера ваще не могу работать" и не нахожу ответа.
Для меня важно, чтоб не тормозило открытие файлов, чтоб табы переключались быстро, чтоб всякие подсказки типа IntelliSense выскакивали без задержек в секунду и более… Т.е. стабильность и плавность постоянно используемого функционала важнее, чем странный комбайн, который после установки требует несколько дней только на то, чтоб отключить все ненужные функции, выскакивающие где не надо. И ещё и денег за это просит.
Так что мой выбор "не пользоваться".
А вот где, кому и что мне говорить — не вам мне указывать.
Итоговое впечатление "всё равно его не брошу, потому что он хороший". А я не выберу MySQL, как хранилище данных, какие бы критерии у проекта ни были — потому что вижу, что потенциального геморроя можно словить на порядок больше, чем… А даже преимуществ-то не вижу. Что, первичная простота развёртывания? Смешно.
Удивительно!
Ну, начнём со ViewState и всего с ним связанного. А с ним связано всё.
Продолжим костылями типа UpdatePanel, мракобесной цепочки HttpModule/HttpFilter/HttpHandler. А на закуску DataBinding в контексте событийной модели — вот там самные прекрасные танцы.
Агада. Прям учит, как надо разделять их. Контролы, на события которых можно подписываться прям в шаблоне, там же рядом прописывая Css-свойства и вставляя туда же биндинги на DataSource…
Возможно, вас память обманывает, скрывая плохое. Но изначально в ASP.NET не было даже precompiled web application и не было code behind. Т.е. весь код, шаблон и css были в одном файле, разделённые самым прекрасным блоком на свете:
Т.е. то, что вы сейчас называете WebForms — это результат тринадцати лет непрерывных попыток костылями и подпорками продержать всё это мракобесие на плаву.
Учитывая, что первый MVC вышел в 2009м году и уже тогда был просто божественным откровением (т.е. ещё шесть лет назад всем было понятно, насколько WebForms несостоятелен) — то ныть сейчас про накопленный багаж "наработок, опыта, сторонних компонентов" довольно самокритично.
Я могу понять вой тех «несчастных», которые сделали ставку на то, чтоб доить разрабов, которые упёрлись в потолок, возникший на пересечении ограничений aps.net из коробки и собственных возможностей… Но что поделаешь. Если не успели поймать ветер mbc, то всё дальнейшее развитие вам тоже будет болезненно.
1. Pre-commit hook это та же клиентская фигня, что и TFVC checkin policy. Тот ещё мрак всем машины настраивать, раскладывая StyleCop и конфиги. А потом ещё обновления велосипедить.
2. Да, бывает ещё серверный pre-receive hook, но если используется git, который в составе TFS, то о нём можно только мечтать. ISubscriber в этом случае — единственный способ.
Есть ещё вариант gated -конфигурации, когда все коммитят в git, который на самом деле проксирует это в другой git и уже на нём (первом) понастроить все эти pre-commit hook… Но это для очень сильных духом.
а вообще есть office365, который за personal (69$/y) даёт на PC пакет Office и 1Tb места к нему (а за Home, 99$/y — Office на до 5ти устройств и по 1Tb на 5 аккаунтов).
Но суть не в этом. Статейка больше про MSBuild, чем про StyleCop.
что, прям вот так? даже в виде примера в статье — заслуживает, чтоб по рукам ;)
Есть такая тема, что когда отдел большой, то со временем «неудобные» вопросы начинают уходить к тихим сговорчивым лидам.