Часто приходится работать за ноутом и ПК одновременно — не весь софт есть и там и там, не весь софт на ноуте работает достаточно быстро, часто нужно прервать работу и ехать на встречу.

Работая таким образом, я, как наверное и многие, периодически пытаюсь мышкой компа что-то щелкнуть на ноуте или передвинуть мышу с ноута на соседний монитор. Особенно это знакомо тем, у кого больше одного монитора на столе.
Теперь это возможно!

Большинство литературы посвященной паттернам в ООП (объектно-ориентированном программировании), как правило, объясняются на примерах с самим кодом. И это правильный подход, так как паттерны ООП уже по-умолчанию предназначаются для людей, которые знают что такое программирование и суть ООП. Однако порой требуется заинтересовать этой темой людей, которые в этом совершенно ничего не понимают, например «не-программистов» или же просто начинающих «компьютерщиков». Именно с этой целью и был подготовлен данный материал, который призван объяснить человеку любого уровня знаний, что такое паттерн ООП и, возможно, привлечет в ряды программистов новых «адептов», ведь программирование это на самом деле очень интересно.
Статья предназначена исключительно для новичков, так что «старожилы» ничего нового для себя не узнают. В основном статья описывает известные паттерны из книги «Приемы объектно-ориентированного программирования. Шаблоны проектирования.», но более популярным и простым языком.

Так уж получилось, что последние пару лет я много работаю с кризисными проектами. Это проекты, в которых деньги потрачены, цели не достигнуты, все сроки много раз нарушены, менеджера уволили или он сам в ужасе сбежал, а уровень мотивации команды – ниже некуда. В общем, материализовавшийся fuck up. К сожалению, большинство таких проектов нельзя просто закрыть – все они важны для заказчика.

От переводчика. На собственном опыте мы знаем, что грамотно выстроенное взаимодействие с клиентом является залогом успешного внедрения ECM-систем. Как адекватно оценить положение дел в организации клиента? Как выявить существующие проблемы и наметить пути их решения? На какие моменты в общении с клиентом следует обратить внимание в первую очередь? Публикаций, посвященных проблемам организации работы по внедрению ECM-решений, в русскоязычном Интернете практически нет. Предлагаем вниманию наших читателей переводной материал, в котором затрагиваются данные вопросы.

Недавно дошли руки до превращения записи моего доклада на AgileKitchen в полноценный слайдкаст.

По моему опыту, в Agile-командах процент собираемых метрик, использующихся для принятия управленческих решений, заметно выше, чем в командах, следующих более консервативным моделям разработки. Однако нужно понимать, что каждое измерение неизбежно содержит в себе ошибку. Перед тем, как принять то или иное решение на основе «аномалий» в наблюдаемых значениях, было бы не плохо понять, что стоит за этой «аномалией»: некоторая особая причина, требующая реакции со стороны руководства, или такое поведение является нормальным для рассматриваемой системы?

В слайдкасте дается намек на то, как в результатах измерений отделить свойства системы от особых причин отклонений, и рассказывается об основных ошибках при использовании данных измерений при принятии управленческих решений.

Введение

Прошло примерно 1.5 года с момента разработки первой версии расширения Regex Tester, я уже писал один пост про его создание. В общем я считаю, что мой первый опыт удался, так как расширение имеет хороший рейтинг и на текущий момент его скачали 12 тыс. раз.
В 2010 году у меня были планы довести расширение до ума. Часть функционала я уже тогда начал реализовывать, но в профессиональной жизни у меня произошло интересно событие — я стал Java-разработчиком, перейдя на другой проект, но это совсем другая история. А сейчас я кратко напишу, что изменилось в новой версии расширения и почему я решил его доработать.

1. Введение

В данной статье я хотел бы рассказать об этих трёх буквах, постоянно находящихся на слуху, но для многих являющихся тайной за семью печатями, а так же привести ряд ресурсов, с которыми неплохо было бы познакомиться при желании продолжить развитие в проектировании на основе предметной области (DDD: Domain Driven Design).

Спасибо небу за то, что в субботу шел дождь, и я это прочитал (а вы скажите спасибо за то, что перевел). В воскресенье, однако, светило солнце и форматирование текста было отложено.

Отдельное спасибо автору, за разрешение отдельной публикации.

Крайне занятная статья о том, что такое бизнес логика и где ей жить. Статье, кстати, уже три года. А я нередко встречаю системы, где код от данных не отделен. Может привести к реальному холивару.

Введение

Обычно, при оптимизации программы для многоядерных компьютеров первым шагом является выяснение возможности разделения алгоритма на части, выполняющиеся параллельно. Если для решения задачи необходимо параллельно обрабатывать отдельные элементы из большого набора данных, то первыми кандидатами станут новые возможности параллельности в .NET Framework 4: Parallel.ForEach и Parallel LINQ (PLINQ)

Parallel.ForEach

Класс Parallel содержит метод ForEach, представляющий собой многопоточную версию обычного цикла foreach в C#. Подобно обычному foreach, Parallel.ForEach выполняет итерации над перечислимыми данными (enumerable), но с использованием множества потоков. Одна из более часто используемых перегрузок Parallel.ForEach выглядит следующим образом:

public static ParallelLoopResult ForEach<TSource>(
			 IEnumerable<TSource> source,
			 Action<TSource> body)

Ienumerable указывает на последовательность, по которой нужно выполнить итерации, а Action body задает делегат, вызываемый для каждого элемента. Полный список перегрузок Parallel.ForEach можно найти здесь.

PLINQ

Родственный с Parallel.ForEach PLINQ представляет собой модель программирования для паралелльных операций над данными. Пользователь определяет операцию из стандартного набора операторов, включающих в себя проекции, фильтры, агрегирование и т.д. Подобно Parallel.ForEach PLINQ достигает параллельности, разбивая входную последовательность на части и обрабатывая элементы в разных потоках.
В статье выделяются различия между этими двумя подходами к параллельности. Разбираются сценарии использования, в которых лучше всего использовать Parallel.ForEach вместо PLINQ и наоборот.

Выполнение независимых операций

Computer Scientist, Software Engineer и Coder заходят в бар.
— О, а вот и программисты! — окликает их бармен...

Я знаю людей, которые программируют уже не один десяток лет, но обижаются, когда их называют "программистами". А по запросу Coder vs Developer vs Software Engineer в гугле находится 113 000 000 ссылок: 1 2 3 4 5 6 7 8 9 … 113 000 000. Что интересно, можно найти совершенно противоположные мнения об одном и том же. С чем-то я согласен, а с чем-то в корне нет.

Последние же несколько лет так вообще постоянно подливают масло в огонь, появляются какие-то совсем странные программисты, которые называют себя Creative Technologist, Creative Coder и Interactive Developer.

Давайте же попробуем разобраться.

Возможно, вы когда-то очень хотели чтобы в вашем приложении присутствовала возможность управления чем-либо через глобальные клавиши. И, возможно, вам нравится программировать с использованием технологии WPF. Тогда этот топик для вас.

Привет, хабрадруг. Считаешь ли ты, что waterfall (каскад) при разработке ПО — это единственный расово-верный подход? Да или нет — спеши под кат.

Вы никогда не задумывались над тем, что навигация в Windows могла бы быть намного удобней? Почему бы не добавить возможность, аналогичную навигации по классам во многих современных IDE, когда в выпадающем списке, вызываемом сочетанием клавиш, отображаются папки с нужным именем, вот так: