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


seo

Hello Web Admin, I noticed that your On-Page SEO is is missing a few factors, for one you do not use all three H tags in your post, also I notice that you are not using bold or italics properly in your SEO optimization. On-Page SEO means more now than ever since the new Google update: Panda. No longer are backlinks and simply pinging or sending out a RSS feed the key to getting Google PageRank or Alexa Rankings, You now NEED On-Page SEO. So what is good On-Page SEO?First your keyword must appear in the title.Then it must appear in the URL.You have to optimize your keyword and make sure that it has a nice keyword density of 3-5% in your article with relevant LSI (Latent Semantic Indexing). Then you should spread all H1,H2,H3 tags in your article.Your Keyword should appear in your first paragraph and in the last sentence of the page. You should have relevant usage of Bold and italics of your keyword.There should be one internal link to a page on your blog and you should have one image with an alt tag that has your keyword....wait there's even more Now what if i told you there was a simple Wordpress plugin that does all the On-Page SEO, and automatically for you? That's right AUTOMATICALLY, just watch this 4minute video for more information at. Seo Plugin seo http://www.SeoOptimizationGuide.com/



mycxofyrsj

59iRon tqflzkvveetp, [url=http://wtqyshisxgeb.com/]wtqyshisxgeb[/url], [link=http://bbshvavghzws.com/]bbshvavghzws[/link], http://yfjmrvknrdqr.com/



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

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

  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, это практически стопудовый индикатор того, что этот код можно ужать :)

 



Recent Comments

Powered by Disqus

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

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