MSBuild не может выполнить один и тот же таргет 2 раза за сборку. Это его принцип работы.
суббота, 12 сентября 2015 г.
четверг, 30 апреля 2015 г.
Linq2SQL WHERE 0 = 1
LINQ2SQL and WHERE 0 = 1
Column.Nullable = true/false
Никогда не забывать это. Вообще никогда.
пятница, 12 сентября 2014 г.
Проблема - не запускается отладка в Visual Studio 2010/12
Если все прочие способы из гугла уже перепробованы, то закройте Steam.
вторник, 27 мая 2014 г.
четверг, 1 августа 2013 г.
Мысли вслух, или не могу больше молчать
Отправили мое резюме в одну фирму. Фирма довольно долго думала и в результате выплюнула следующее:
"У нас командная работа (Scrum) и удалённая разработка из дома неприемлема. Только полный рабочий день и тесная работа в команде.
В остальном, кандидат конечно интересный."
Ай, как я люблю такие фирмочки. Сказать что над этим комментарием мы ржали в составе 35 человек из числа распределенной команды iDecide - ничего не сказать. Мы уже давно придерживаемся идеологически достаточно строгого agile и, хоть официально и не рекомендуется, работаем все удаленно (исключение составляет управление и маркетинг). И ничего, подчеркиваю, ничего не случилось плохого. Почему? Да потому что топы компании и среднее звено руководства - весьма и весьма грамотные люди, которые построили процесс, создали идеологию и (ВНЕЗАПНО!) все прекрасно работает и не разваливается.
Ребята, ну все же очевидно! Подобного рода утверждения обычно означают: "Нетнетнет! Нам нужен жесткий контроль над ВСЕМИ сотрудниками! Иначе никак!". Особенно прикрываться SCRUM-ом от удаленной работы - это как прикрываться веганством от жесткого, неистового секса.
Потребность в строгом контроле и абсолютное неприятие удаленной работы свидетельствует только об одном - сюрприз-сюрприз - были прецеденты, когда без такого управления, команда шла вразнос, люди теряли фокус и тупо забивали на работу. Что, в свою очередь, недвусмысленно намекает что команда собрана из несамостоятельных и ленивых людей + руководство не знает что с ними делать. А тогда какой у вас, к херам собачьим, SCRUM?! Нет, это в лучшем случае корявый Waterfall. Потому что нельзя построить SCRUM на паноптикуме таких вот кадров. Ну не будет это работать - плавали уже, знаем.
Тем не менее, представители надувают щеки и прикрываются умными словами. Господа, к чему надменность? Все мы вылезли из женской вагины. Вас никто не заставляет публично расписываться в своем (не)профессионализме (на минутку, что вы и делаете, говоря про SCRUM и удаленку в таком ключе). Можно просто сказать "мы не заинтересованы в удаленном сотрудничестве", или "сожалеем, но политика компании не подразумевает такого формата". Лучше честно сознаться что "не хотим, не будем", чем понапрасну умничать. Фу.
Тут можно было еще сказать что в нашем, академовском community любой мелкий аутсорсер, чуть только доросший до интегратора - мнит себя чуть ли не Газпромом и Microsoft-ом в одном лице. Но я не буду распинаться - это все итак понятно. Интересно только откуда эта надменность? Неужели НГУ так влияет?
четверг, 11 июля 2013 г.
среда, 27 марта 2013 г.
Thread vs ThreadPool
Внимательно следите за этими двумя сущностями. ThreadPool удобнее и логичнее в ряде случаев, но иногда может подложить свинью. А именно - когда функциональность, которая должна выполняться в одном, но параллельном потоке ВНЕЗАПНО раскладывается на кучу потоков.
Это реально может послужить причиной многих багов. В общем - контролируйте потоки в своем приложении. Thread - для более тонкого планирования многопоточности. ThreadPool - быстрое, но потенциально грабельное решение.
Подписаться на:
Сообщения (Atom)