Ну тут есть еще тонкости, начиная с четвертой ступени людей не очень-то берут со стороны :) Вакансий на тим-лида/архитектора очень мало. И это вполне логично — ответственность у позиции высокая, а 100% качественных методов отбора еще не придумали.
Но для начинающих метод «смени компанию» часто весьма неплох, соглашусь.
Пост о депозитах и дебетовых картах. Там списаний никаких нет. Там, вообще говоря, есть только начисления, иногда достаточно неожиданно-приятные (я про кэшбэк, например) :)
Сам пользуюсь, впечатления исключительно положительные.
Если компания делает по 20 шаблонных сайтов в месяц — у неё наверняка есть своё подобное решение.
Если каждый сайт, который вы делаете более-менее уникален и разработка достаточно длительная — то поддерживать «универсализированно-гибконастраиваемое» решение подчас заметно сложнее, чем скопипастить заготовку и отредактировать её под потребности проекта. И код в каждом отдельном проекте получится проще и поддерживать его будет легче (в частности, url-адреса будут прямо в месте их единственного использования, в контексте, а не в «настраиваемых» переменных).
а когда фримиум софт после ввода ключа неожиданно приобретает новые (ранее скрытые в UI) функции — вы тоже возмущаетесь, что получили софт бесплатно, а он работал не на полную мощность? Ведь софт ничего дополнительно не скачивал, значит сразу всё умел — почему же он работал на 70% возможностей?
Эта фича будет «компилироваться» только в .net 4.5?
А то если будет в .net 4, то возможна ситуация, что один и тот же код скомпиленный в VS2010 (со старым поведением) не работает, а в VS11 — работает. Совместное использование студий будет тогда проблематично.
Ну в принципе автоопределение сторонних тоже было бы хорошо.
Или по аналогии с SL и DomainServices тоже могло бы неплохо смотреться.
А так — RESTfulы можно и на «традиционных» сервисах делать и отдавать тот же json. В чем тогда будет плюс WebAPI? Да, инфракструктура asp.net с DI, валидацией и прочим — это хорошо, но если в функционале будет явный пробел, то вопрос, в чью сторону выбор будет.
>> You will see some auto-generated classes for some use-cases with some of the higher-level libraries we are doing on top of Web API. For example, some of the data libraries we are doing will do this.
Очень общие слова, конечно :)
Ну и собстна если майкрософт не озаботится, энтузиасты сделают, я думаю. У самого были планы добавить метадату и Т4-шаблончик для клиента нарисовать, но бежать впереди паровоза пока рановато :)
Если не сделать ничего, то у WSDL останутся неоспоримые преимущества, придется активно поддерживать и то, и другое :)
А намерение свести всё в WebAPI насколько я понимаю всё-таки есть
Через год найти других может быть проблема.
Если ушедшие расскажут о том, что перспектив в компании особо никаких. Конечно, всё равно найдутся те, кто пойдут опыт зарабатывать, чтобы через год уйти, но немногие всё же планируют раз в год менять работу :)
А насколько корректно включать в выборку заведомо «особенные» точки?
Будь в неделе 8 дней и 3 выходных, в первом примере понедельник оказался бы «обычной» точкой.
На примере получилось, конечно, весьма наглядно, но стоит ли в реальных оценках поступать так же?
Ну вот только возводить этот принцип в абсолют, имхо, не самая лучшая идея.
Не буду же я тестировать, например, логирование. И он мне покажет Survived на каждом вызове лог-функции.
Но смотреть и анализировать результаты время от времени, безусловно, полезно :)
Ну так асинхронные методы же явно помечать надо как async.
Я не думаю, что люди, которые в своём развитии дошли до осознания необходимости маленьких методов, будут делать каждый такой метод асинхронным :)
Во-первых, с самого начала возникла необходимость из шаблона обращаться к методам основного объекта веб-приложения (назовем его Main) — например, конфигурация, менеджер тем, к методам вызывающего контроллера и так далее.
По MVC-шной идеологии в норме не должно быть необходимости из View обращаться к внешним ресурсам — вьюшка получает модель со всем необходимым. Я не прав? :)
ControlHelper — он реализован как свойство базовой страницы для удобства использования? Это не набор статических по сути хэлперов?
Про разметку МастерПейджФайла тегами, к сожалению, не понял идею. Возможно, потому что апологет Razor'a… :)
Если заказчик по каким-то причинам уже решил, что будет работать с вами — то всё хорошо. Это значит, у него есть к вам доверие. Тогда можно убедить, что для него самого оплачивать часы фактической работы лучше, чем фиксед прайс с заложенными рисками и бюрократией при попытках что-то поменять в проекте.
А если у него доверия к вам нет — работаете первый раз? «Я буду оплачивать часы, а они будут балду пинать, в чем их заинтересованность сделать быстрее?».
А если заказчик в поиске среди нескольких исполнителей — то вот тут будут сложности. Цена проекта здесь для него — сравнительная характеристика. И если 3 команды готовы «сказать цену», а вы — убеждаете работать по-другому, то не факт, что он вообще захочет слушать вашу аргументацию :)
Можно сказать — ну и не работайте с такими заказчиками. Так сказать можно, если потенциальных заказов у вас миллион. А если нет?
Статья хороша хотя бы тем, что в ней есть конкретные цифры, от которых можно оттолкнуться, когда оценивать всё-таки приходится.
И как раз на небольших проектах, где «примерный ориентир» в 1-2 месяца вроде бы очевиден, расчеты помогут не забыть включить/обдумать тестирования и поставку отдельно.
А мне показалось, что основной мессадж как раз не в том, что «мы стали делать больше/быстрее», и не в том, что «менеджеры у нас такие молодцы», это просто красивая история хорошей компании, в которой хороши все. Одна строчка про КПД — это ж не ключевой момент вовсе.
И как раз труду простых разработчиков/техподдержки большой реверанс сделан.
Может ли кто-нибудь привести примеры подобных инструментов? Что используется/как это интегрируется, например, с билд-сервером?
Как-то я подзабыл, что версия это не название… видимо из-за vs10 == VS2010 :)
> Вышла Release Candidate версия Visual Studio 11.
И на официалке майкрософтовской: «Visual Studio 2012 Release Candidate».
Так как она всё-таки называется? :) VS 11 или VS 2012?
Но для начинающих метод «смени компанию» часто весьма неплох, соглашусь.
Сам пользуюсь, впечатления исключительно положительные.
Если каждый сайт, который вы делаете более-менее уникален и разработка достаточно длительная — то поддерживать «универсализированно-гибконастраиваемое» решение подчас заметно сложнее, чем скопипастить заготовку и отредактировать её под потребности проекта. И код в каждом отдельном проекте получится проще и поддерживать его будет легче (в частности, url-адреса будут прямо в месте их единственного использования, в контексте, а не в «настраиваемых» переменных).
Остерегайтесь общей инфраструктуры! :)
А то если будет в .net 4, то возможна ситуация, что один и тот же код скомпиленный в VS2010 (со старым поведением) не работает, а в VS11 — работает. Совместное использование студий будет тогда проблематично.
Или по аналогии с SL и DomainServices тоже могло бы неплохо смотреться.
А так — RESTfulы можно и на «традиционных» сервисах делать и отдавать тот же json. В чем тогда будет плюс WebAPI? Да, инфракструктура asp.net с DI, валидацией и прочим — это хорошо, но если в функционале будет явный пробел, то вопрос, в чью сторону выбор будет.
>> You will see some auto-generated classes for some use-cases with some of the higher-level libraries we are doing on top of Web API. For example, some of the data libraries we are doing will do this.
Очень общие слова, конечно :)
Ну и собстна если майкрософт не озаботится, энтузиасты сделают, я думаю. У самого были планы добавить метадату и Т4-шаблончик для клиента нарисовать, но бежать впереди паровоза пока рановато :)
Если не сделать ничего, то у WSDL останутся неоспоримые преимущества, придется активно поддерживать и то, и другое :)
А намерение свести всё в WebAPI насколько я понимаю всё-таки есть
Если ушедшие расскажут о том, что перспектив в компании особо никаких. Конечно, всё равно найдутся те, кто пойдут опыт зарабатывать, чтобы через год уйти, но немногие всё же планируют раз в год менять работу :)
Будь в неделе 8 дней и 3 выходных, в первом примере понедельник оказался бы «обычной» точкой.
На примере получилось, конечно, весьма наглядно, но стоит ли в реальных оценках поступать так же?
Не буду же я тестировать, например, логирование. И он мне покажет Survived на каждом вызове лог-функции.
Но смотреть и анализировать результаты время от времени, безусловно, полезно :)
Двусмысленный пунктик получился.
Ну так асинхронные методы же явно помечать надо как async.
Я не думаю, что люди, которые в своём развитии дошли до осознания необходимости маленьких методов, будут делать каждый такой метод асинхронным :)
По MVC-шной идеологии в норме не должно быть необходимости из View обращаться к внешним ресурсам — вьюшка получает модель со всем необходимым. Я не прав? :)
ControlHelper — он реализован как свойство базовой страницы для удобства использования? Это не набор статических по сути хэлперов?
Про разметку МастерПейджФайла тегами, к сожалению, не понял идею. Возможно, потому что апологет Razor'a… :)
А если у него доверия к вам нет — работаете первый раз? «Я буду оплачивать часы, а они будут балду пинать, в чем их заинтересованность сделать быстрее?».
А если заказчик в поиске среди нескольких исполнителей — то вот тут будут сложности. Цена проекта здесь для него — сравнительная характеристика. И если 3 команды готовы «сказать цену», а вы — убеждаете работать по-другому, то не факт, что он вообще захочет слушать вашу аргументацию :)
Можно сказать — ну и не работайте с такими заказчиками. Так сказать можно, если потенциальных заказов у вас миллион. А если нет?
Статья хороша хотя бы тем, что в ней есть конкретные цифры, от которых можно оттолкнуться, когда оценивать всё-таки приходится.
И как раз на небольших проектах, где «примерный ориентир» в 1-2 месяца вроде бы очевиден, расчеты помогут не забыть включить/обдумать тестирования и поставку отдельно.
И как раз труду простых разработчиков/техподдержки большой реверанс сделан.