Если посмотреть на девяностые годы прошлого века, то они дали большое количество методологий (если кому больше нравиться фреймворков) разработки программного обеспечения: FDD (Feature driven development), Scrum, Rup, XP. Но самыми востребованными оказались не технические подходы, а ориентированные на людей. В 2001 году это все привело к появлению Agile-манифеста. Не надо нам качества, не надо нам поддержки изменений, дайте нам быстро то, на что можно посмотреть, а уж мы примем решение, что делать дальше. В настоящее время складывается ощущение, что социальные факторы себя исчерпали и для дальнейшего повышения скорости их уже не хватает. Подход, включающий не только «про людей», но и «про технологии», получил название DevOps. Давайте посмотрим на чем еще мы можем выиграть в скорости поставки полезности.

В комментариях к предыдущей статье "О чем молчит диаграмма Ганта или почему проекты всегда опаздывают" накидали ссылок на видео и слайдкасты, описывающие и другие причины вызывающие ошибки при использовании диаграмм Ганта. Наибольшее обсуждение и недопонимание вызвало выпрямление сроков обусловленное несимметричностью распределения срока решения задачи. Под катом пример влияния на срок окончания проекта этого самого несимметричного распределения.

Каждый раз, когда я смотрю на диаграммы Ганта [1], меня мучает один и тот же вопрос. Как? Вот как можно быть уверенным, что ресурс А, выполнит задачу Б за 5 дней? Нет, я понимаю, что есть исторические данные, есть, не побоюсь этого слова, статистика. Но вот как можно на основе всего этого делать уверенные прогнозы? Я не понимаю.
Если для вас термины «взаимозависимость событий» и «статистические отклонения» говорят что-то не только по отдельности, но и в совокупности, то статья вас вряд ли заинтересует. А вот если эти термины, употребленные в одном контексте, не говорят вам в чем проблема диаграмм Ганта, то приглашаю под кат, где на простом примере мы это и обсудим.

В последнее время, стало модным, помимо поясняющей надписи для TextBox-а еще и на самом TextBox-е писать некоторую подсказку. Должно все это выглядеть так, как на картинке для привлечения внимания. Пока пользователь ничего не ввел, подсвечивается подсказка. Если пользователь ввел текст, то подсказка не показывается. Не бог весть, какая сложная логика, но т.к. у ControlTemplate в Windows Store приложениях отобрали триггеры, то придется это делать не стилем, а именно новым элементом управления.
Под катом, будем пошаговое руководство, по разработке такого компонента, ориентированное на тех, кто первый раз подходит к разработке своих элементов управления. Для тех, кто уже программирует под Windows Store откровений не будет, но если не сложно, выложите рекомендации в комментариях, может кто-то действительно решит сделать хороший элемент управления для такой задачки.

Добрый день, хабраюзеры.

Пост больше подошел бы для пятницы, но пока идет обед… Давайте отпишусь о паре забавных опытов получить полезность от, как я написал в заголовке, ведущего российского телекома.
Под катом, собственно, две истории, первая произошли достаточно давно, тогда у этого телекома было другое название, а вот вторая — происходит в наши дни. Да, в конце будет еще один вопрос, но это уже лирика.

Приведенные истории, не претендуют на оригинальность и происходят постоянно, причем не только с телекомами. Но, я надеюсь, прочитав, вы улыбнетесь (вроде истории забавные), ну, и организовав свой бизнес и вырастив его до таких же размеров, будите уделять чуть больше внимания тому, что называется клиентоориентированностью.

Как вы не знаю, но я себя на этой картинке узнал. Ведь, согласитесь, когда проектируется архитектура приложения, все красиво, логично и соответствует лучшим мировым практикам. Но в процессе работы, сталкиваясь с ограничениями предъявляемыми архитектурой, мы зачастую думаем: «Вот здесь немножко нарушу, это ведь сэкономит мне час времени разработки. Ну а потом, как будет время, поправлю». Но, почему-то, это время так никогда и не наступает. На мой взгляд, единственным способом заставить себя, как программиста, следовать разработанной архитектуре, это научить среду разработки все отклонения и костыли показывать как ошибки компиляции. В этом случае, если код плох, он сразу будет исправлен, ну а если архитектура устарела, то будет исправлена она. Т.е. в хранилище кода всегда будет код соответствующей запланированной архитектуре.
Пара слов, о том, что будет подкатом:
1. Небольшая преамбула.
2. Восстановление архитектуры по имеющемуся проекту.
3. Настройка Visual Studio и TFS для автоматического контроля архитектуры.
Под катом много картинок и желание все описанное попробовать.

Добрый день, коллеги.

Длинные праздники заканчиваются, и уже завтра, мы снова погрузимся в пучину ежедневной рутины. Сегодня, на стыке еще не закончившихся праздников и еще не начавшейся рабочей недели, я бы хотел немного рассказать о непрерывной интеграции.
Начиная внедрять Agile практики в разработке, многие, прочитав: «Личности и их взаимодействия важнее, чем процессы и инструменты», приходят в восторг. Ведь можно собрать команду, сплотить их, поставить задачи и вот она: «звезда пленительного счастья» (работающее и полезное пользователям ПО). Но, к сожалению, в жизни бывает все намного скучнее и непредсказуемей. Начиная внедрять новомодный Scrum или Kanban, часто забывают, что все достоинства этих методик проявляться только в том случае, если они ложатся на правильные инженерные практики. К таким практикам относят модульное тестирование вообще, и TDD в частности; парное программирование; Code Review; непрерывную интеграцию и многое другое.
Под катом, я попробую показать, как настроить непрерывную интеграцию в рамках TFS 11 и в каких сценариях, какой способ построения проектов будет наиболее оправдан (много картинок и текста).

В настоящее время, стать первопроходцем в географии достаточно сложно. Есть физика, химия, биология… Но там слово первопроходец несет немного другой смысл. Да, они тоже идут в неизведанные области, но все равно это как то не так. Нас, программистов, так же как биологов и etc, относить к первопроходцам тяжело. Но есть люди, с которыми мы часто спорим, но именно они истинные первопроходцы современности. Именно им, приходиться лезть в дебри наших интерфейсов, разбираться в сложных взаимосвязях наших ошибок, да и, что уж греха таить, ворчать на нас, за отсутствие торных путей.
Ладно, с лирикой завязываю, начинаю по теме. Те кто был на QADay и слушал Чарлза Стерлина, в принципе дальше может не читать, кстати, все кто уже пробовал Exploratory Testing, в принципе тоже. Для остальных, позвольте коротенько рассказать о исследовательском тестировании при помощи Visual Studio 11 и, соответственно, TFS 11.
Вперед, в пампасы?

Большинство источников по использованию атрибутов [1, 2] рассказывают, что они есть, «обеспечивают эффективный способ связывания метаданных или декларативной информации с кодом», могут быть получены при помощи отражений [3]. В рамках данной статьи, я попробую показать прикладной пример применения атрибутов: проверка заполненности обязательных полей на форме добавления/редактирования нового бизнес-объекта.
Перед тем, как вы нажмете подробнее, несколько предупреждений:
1. Если вы уже работали с атрибутами, то, возможно, вам будет неинтересно.
2. При написании демонстрационного примера были допущены существенные упрощения (например, отказ от MVVM), с целью облегчения восприятия материала про атрибуты.

Первое впечатление от интерфейса очень напоминает то ощущение, которое вызвал Microsoft Office 2007 после 2003. И если первое время скорость работы с 2007 была заметно ниже, то уже через пару недель было не очень понятно, чего это мне здесь не нравилось. С Visual Studio 11, по всей видимости, будет так же.

 

Для комментария к топику многовато, поэтому, с вашего позволения отвечу топиком.

Начиная читать статью, был полностью согласен, как нельзя оценивать эффективность, но дойдя до как можно, стал в очень многом не согласен. О чем я? Смотри далее…

Сегодня пришел студент-задолжник сдавать программирование.
На тривиальный вопрос:
— Что такое логические операторы?
Я получил великолепный ответ:
— Это операторы которые возвращают одно из двух: либо «и», либо «или», либо «не».

Ну и вспомнилось из ТЗ на курсовую работу, в разделе «требования к программному обеспечению»:
«Программа должна иметь программиста»

Удачного дня нам всем ;)

Большая часть прогресса, который мы наблюдаем за окном, это результат человеческой лени. Лень было красить забор кисточкой, изобрели валик. Лень было красить валиком, изобрели пульверизатор. Ну Вы поняли. Какое это все имеет отношение к программированию? Самое непосредственное!

Друг

Первые программисты манипулировали такими понятиями как «0» и «1» и это было долго и непонятно. Человеческая лень предложила при помощи ноликов и единичек написать программу преобразующую MOV, ADD, JMP в новые нолики и единички, понятные процессору.

На Хабре, в новостях и на многих-многих интернет ресурсах обсуждают наше российское образование, хорошее оно или плохое, учат или нет, а если учат, то кого? Я попробую посмотреть на эту проблему немного с другой стороны — со стороны преподавателя ВУЗа пытающего сеять разумное, доброе и местами вечное.