Без использования unit-тестов и TDD очень легко выстрелить себе в ногу. С тестами и TDD сделать это намного сложнее, но если у вас получится, вы останетесь без ноги.

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

В этой статье я постараюсь объяснить о чем, собственно, разговор. Для чего нужно TDD и как его аккуратно использовать.

Что такое TDD в двух словах? — это написание разработчиком тестов до реализации функциональности.
По совету Роя Ошерова разобьем вопрос применимости TDD на два:

• Зачем писать тесты?
• Зачем писать тесты до реализации?

Вдохновившись статьей о поиске следов взлома, решил написать статью о предупреждении взлома и базовых шагах для сведения возможности взлома сервера к минимуму.
Все шаги крайне важны, и невозможно выделить самый-самый важный, либо второстепенный.
Данная статья не является пошаговой инструкцией, а лишь списком рекомендуемых шагов.

HgAssist — repositories are synced!

Пользуясь системой управления кодом Mercurial мы часто сталкивались с тем, что забывали делать push после того, как в локальный репозиторий были сделаны комиты.

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

Поэтому мы написали HgAssist.

Здравствуйте.
В продолжение тематики самостоятельного изучения схемотехники предлагаю вашему вниманию статью, связанную с синтезом автоматов на триггерах.
А начинается все так:

Фильтры — мы сталкиваемся с ними постоянно, они на сайтах и в приложениях. У кого, при поиске той или иной информации, не возникала мысль: «Здесь бы фильтр не помешал»?

Мы предлагаем поговорить о фильтрации. Зачем она нужна? Ведь кто ищет, тот всегда найдет? И проанализирует? Или все же нет?

Предположим ваш сайт или приложение содержит необходимую для пользователя информацию, причем в большом объеме. Обратиться ли пользователь к Вам? Да, конечно. В худшем случае человек просто запутается в объеме данных, в лучшем сможет самостоятельно отобрать необходимое и отправиться сводить и анализировать все предоставленное ему в отдельных документах и таблицах, которые он будет создавать самостоятельно. Вернется ли он к вам, или пойдет искать более удобное представление необходимым ему данным? Скорее второе.

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

Почти все разработчики знают, что кэш процессора — это такая маленькая, но быстрая память, в которой хранятся данные из недавно посещённых областей памяти — определение краткое и довольно точное. Тем не менее, знание «скучных» подробностей относительно механизмов работы кэша необходимо для понимания факторов влияющих на производительность кода.

В этой статье мы рассмотрим ряд примеров иллюстрирующих различные особенности работы кэшей и их влияние на производительность. Примеры будут на C#, выбор языка и платформы не так сильно влияет на оценку производительности и конечные выводы. Естественно, в разумных пределах, если вы выберите язык, в котором чтение значения из массива равносильно обращению к хеш-таблице, никаких результатов пригодных к интерпретации вы не получите. Курсивом идут примечания переводчика.