Последние записи


Запуск тестов по порядку

Все современные ранеры тестов обладают следующими характеристиками:

  1. Тесты запускаются в произвольном порядке
  2. Тесты запускаются паралельно

Это сделано с благими намерениями. Первая фича позволяет отловить зависимые тесты, это когда одни тесты влияют на другие. И результаты запусков тестов могут отличаться, в зависимости, в каком порядке они запускались. Вторая фича позволяет быстрее выполнять тесты, выполняя их паралельно.

Но иногда нам нужно выполнить тесты последовательно. Порядок может быть произвольным, но два теста не должны быть запущены в один момент. Такое часто бывает необходимо для интеграционных тестов. Собственно, написать этот пост меня побудила работа над тестом, который взаимодействует с файловой системой. Читать дальше >>



Неприменяемый патч

Пробовал я как-то сделать патч и сходу уперся в стену.

Вот примерный список шагов для воспроизведения (делал в powershell):

mkdir hg-test
cd hg-test
hg init
notepad a.txt 
hg add .
hg commit -m 'first commit'
notepad a.txt 
hg commit -m 'second commit'
hg export tip > patch.patch 
hg strip tip 
hg import patch.patch
 
applying .\patch.patch
abort: .\patch.patch: no diffs found
 

тут мы создаем репозиторий, добавляем в него файлик, комитим (6), потом меняем и снова комитим (8). После этого делаем патч (9), удаляем последний коммит (10) и пробуем применить свежесозданный патч (11). Строки 13 и 14 переводятся, как "пошел нафиг" по Меркуриаловски. Читать дальше >>



Приближаем репозитории

На нашем проекте используется много Mercurial репозиториев. Их больше одного, они достаточно большие, находятся далеко и склонировать их занимает порядочно времени. Логичным решением для нас стал перенос их в наш офис, поближе и к разработчикам и к нашему билд серверу. 

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

Мы использовали такой сценарий на одном из прошлых проектов, когда все команда была в нашем офисе, и нам нужно было только заливать наши изменения во вселенский (центральный для компании) репозиторий. Это было сделано с помощью еще одной билд конфигурации Teamcity, которая следила за локальным репозиторием и с помощью command line шага hg push отлично пушила изменения. Текущая ситуация обострилась тем, что репозиториев стало больше и синхронизация должна стать двухсторонней, поскольку команды не из нашего офиса в них тоже активно производят изменения. Читать дальше >>



git vs hg

Недавно в моем окружении опять материализовался спор, что круче, mercurial или git. Я имел удовольствие плотно поиспользовать оба продукта и хочу изложить свое видение вопроса. Букв получилось много, поэтому это будет серия из нескольких постов.

Disclaimer

Последние полгода время я практически постоянно пользовался git. До этого большую часть занимал mercurial, и уже вторую неделю акцент основательно сместился в сторону последнего. Если вдруг покажется, что по моим выводам git получается лучше, чем hg, то это или правда, или я еще не вспомнил всей крутости меркуриала. Читать дальше >>



Пример из жизни про чистый код

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

Тема наверное уже достаточно избитая, но тем не менее периодически встречаются холивары по этому поводу. Особо упоротые менеджеры (а иногда и разработчики) считают чистый код абсолютно бесполезным девелоперским фетишем. Мол, бизнесу пофиг, чо там за код -- главное, чтобы он работал. Некоторые в конце после паузы добавляют слово "без ошибок" или "правильно". Читать дальше >>



Как стремительно вывести много переменных в лог

Допустим, у вас есть некоторое количество legacy кода, и вам нужно понять, как и что в нем работает. Цепочки вызовов длинные, перегрузок методов много, и вам интересно, какие из них вызываются в конечном итоге. Можно, конечно, запустить отладчик, но у меня стойкое ощущение, что практически всегда в случаях, когда руки тянутся к отладчику, существуюет более удобное и быстрое решение. Практически в 100% таким решением будет банальный вывод значений интересующих нас переменных в консоль:

Console.WriteLine("v = " + v);

Это достаточно эффективная практика сама по себе, ведь добавив в нужные места такой вывод и запустив юнит тест, мы получим на выходе лог, над которым можно потупить и понять что к чему. Если же мы очень везучие и у нас есть возможность использовать NCrunch, то мы вообще будем видеть этот лог в реальном времени (меняем код --> меняется лог). Читать дальше >>



Ковровые бомбометания спасают вечер

Такая вот задача: есть интерфейс с методом

public void Setup();

И есть стопятсот его реализаций (на самом деле 92, но это достаточно немало для нашего сценария, как мы дальше увидим). На каком-то этапе разработчиков посетила мысль, что этот метод фактически выполняет роль конструктора и должен быть выпилен как из интерфейса, так и из классов. А логика из него должна быть перенесена в конструктор. Достаточно простое задание, но при этом весьма рутинное.

Вопрос: как сделать это наиболее оптимально?

Как вы уже могли догадаться, на помощь приходят регулярные выражения. В VS2012 (это важно — в предыдущих версиях синтаксис регулярных выражений несколько другой, если интересно — дайте об этом знать, я и для них опубликую выражение) открываем окошко Replace in Files (Ctrl-Shift-H), там выбираем режим Use Regular Expressions (Alt-E) пишем в строку найти:

(public class (\w+)(.|\n)*public )override void SetUp

а в строку заменить:

$1 $2

После этого в Scope выбираем Entire Solution и жмем Replace All (Alt-A).

Вуаля! Осталось только пройтись по ошибкам, ведь в некоторых классах уже есть конструкторы и компилятор может выразить свое недовольство, но в моем случае таких ошибок намного меньше, чем 92, и их очень быстро можно исправить. Исправляем, прогоняем тесты, комитим, пушим и думаем, на что можно потратить освобожденные час-полтора (может пост накатать в блог?). 

Если вам интересна расшифровка этого выражения, дайте знать — опубликуем в следущий раз :)



Словари, сортировки и меньше кода

Задача: есть словарь, нужно вернуть все строки, отсортированные по ключу, в одной большой строке. Это делает следующий код:

public static string Compose(Dictionary<string, string> xmls)
{
    var builder = new StringBuilder();
    var sorted = xmls.OrderBy(k => k.Key).Select(k => k.Value);
    foreach (var xml in sorted)
    {
        builder.AppendLine(xml);
    }
 
    return builder.ToString();
}

Вроде бы все правильно, но ведь можно этот код уменьшить. Достаточно просто вспомнить про String.Join():

return String.Join(Environment.NewLine, xmls.OrderBy(p => p.Key).Select(p => p.Value));

Или вообще убрать ручную сортировку:

return String.Join(Environment.NewLine, new SortedDictionary<string, string>(xmls).Values);

Оба последних варианта и выглядят короче и работают быстрее. Вообще, если вы видите в коде конструкцию foreach, это практически стопудовый индикатор того, что этот код можно ужать :)

 



ConEmu: Новый лидер моего хитпарада консолей

Мне уже когда-то советовали попробовать ConEmu, и сейчас вот опять в коментариях к посту про консоли я увидел упоминание о ней. В прошлый раз я попробовал поставить, но чего-то не пошло. Но в этот раз я поставил и мне она понравилась. Про нее тоже писал Ханселман и ее можно поставить через Chocolatey: cinst conemu. 

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

К тому же это приложение активно развивается и вообще -- весьма здоровское. Так что смело рекомендую всем любителям консоли попробовать его.



Консоль или GUI?

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

Что тут сказать. Раньше я тоже не понимал прелестей консоли. Но сейчас без нее мне неудобно. И в консоли я могу делать многие вещи значительно быстрее, чем мышкой и кнопочками.

Конечно, стандартный cmd в Windows весьма убог и заслуженно вызывает насмешки наших Unix - ориентированных братьев по разуму. Но, к нашей радости, есть другие решения, которыми я и хочу поделиться. Читать дальше >>



Recent Comments

Powered by Disqus

Что еще почитать:

Arrange Act Assert
Ayende @ Rahien
Alexander Beletsky
Rinat Abdullin
Happy PM
it4business
Scott Hanselman