Архив рубрики: Редкое

Прыжки с парашютом

Майские праздники я провел в DZ Menzelinsk (http://www.skyjump.ru/). Это было мое первое знакомство с небом и воздушным потоком в принципе. Именно поэтому было очень забавно, когда несколько инструкторов последовательно задавали  одни и те же вопросы:
— Тандем прыгал?
— Нет.
— А в трубе летал?
— Нет.
— Т.е. вот так сразу AFF еще не зная как оно вообще?
— Да.
Тут было что-то похожее на 

К моему сожалению попрыгать вволю не вышло т.к. несколько дней просто не было погоды. Тем не менее, несколько прыжков сделать все таки удалось, а когда погода брала своё  — с пользой проводил время в Самарской аэротрубе.

Читать далее

Если Вы нашли ошибку, пожалуйcта выделите ее и нажмите Shift + E или нажмите здесь чтобы информировать меня. Спасибо.

Оптимизация?

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

Дважды два четыре

Почему это не могу

Но ведь я знаю что дважды два четыре

А ведь и правда не могу, я просто знаю ответ и не пытаюсь считать…

Что-то в этом духе пронеслось у меня в голове в ту секунду, но разговор начался совсем с других рассуждений.

Читать далее

Если Вы нашли ошибку, пожалуйcта выделите ее и нажмите Shift + E или нажмите здесь чтобы информировать меня. Спасибо.

Питер Уоттс — Ложная слепота

Читая сборник цитат (уже не помню на какую тему), наткнулся на следующее утверждение:

Наши органы чувств выдают столь фрагментарные и несовершенные данные, что мозг вынужден интерпретировать их на основе оценок вероятности, вместо того чтобы воспринимать напрямую. Он не столько «видит» мир, сколько гадает о нем.

Сама по себе мысль для меня не явилась открытием, но породила желание прочитать произведение целиком…

Читать далее

Если Вы нашли ошибку, пожалуйcта выделите ее и нажмите Shift + E или нажмите здесь чтобы информировать меня. Спасибо.

Люди-великаны

Нагло спертый текст из какого-то тизера, которым группы в соц-сетях стараются заманить себе посетителей. На этот раз он меня реально позабавил по нескольким причинам.

1. Естественно нельзя доверять на слово подобной писанине, пусть она и с картинками. Нужно искать подтверждения в других источниках и т.п.

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

3. Ну и вспомним тех же Атлантов и прочих, кто судя по описанием был весьма велик…

Раньше Землю населяли люди-Великаны!

Этот факт не придается огласке, т.к. он не вписывается в современную теорию эволюции Дарвина, но факт остаётся фактом: нашу Землю населяли люди -Великаны и даже сосуществовали с современным человеком.В доказательство этому вы сможете увидеть многочисленные фото и научные факты, которые годами замалчиваются.

Ниже мы приведем факты о существовании этих существ:

1. В 1979 году в Мегалонг Взлли в Голубых горах местные жители нашли огромный торчащий над поверхностью ручья камень, на котором виднелся отпечаток части огромной стопы с пятью пальцами. Поперечный размер пальцев составлял семнадцать сантиметров. Если бы отпечаток сохранился полностью, то имел бы 60-сантиметровую длину. Отсюда следует, что отпечаток оставил человек шестиметрового роста.
2. Иван Сандерсон, известный зоолог с мировым именем, однажды поделился любопытной историей о полученном им от некоего Алана Макшира письме. Автор письма в 1950 году работал бульдозеристом на строительстве дороги на Аляске и сообщал, что рабочие обнаружили в одном из могильных холмов два огромных окаменелых черепа, позвонки и кости ног. Высота черепов достигала 58 см, а ширина 30 сантиметров. Древние гиганты располагали двойным рядом зубов и непропорционально плоскими головами. Позвонки, так же как и черепа, имели размер в три раза больший, чем у современного человека. Длина костей голени составляла от 150 до 180 сантиметров
3. В 1899 году шахтеры Рурской области в Германии обнаружили окаменелые скелеты людей ростом от 210 до 240 сантиметров.
4. В Южной Африке на алмазных разработках в 1950 году был обнаружен фрагмент огромного черепа высотой 45 сантиметров. Выше надбровных дуг находились два странных выступа, напоминающие маленькие рога. Антропологи, в руки которых попала находка, определили возраст черепа – около девяти миллионов лет.
В самых различных источниках есть много документальных сведений о великанах. Приведём некоторые из них.
5. В Южной Африке на реке Окованго аборигены рассказывают о живших в прошлом в этих местах гигантах. В одной из их легенд говорится, что «гиганты были наделены невероятной силой. Одной рукой они перегораживали течение рек. Их голоса были такими громкими, что доносились из одного селения в другое. Когда кто-нибудь из великанов кашлял, птиц словно ветром сдувало.
6. На охоте они проходили за день сотни километров, а убитых слонов и гиппопотамов легко вскидывали на плечи и относили домой. Их оружием были луки, изготовленные из стволов пальм. Даже земля носила их с трудом».
7. А инкские легенды рассказывают, что во времена царствования Инки XII Аятарко Кусо со стороны океана на громадных камышовых плотах в страну прибыли люди столь огромного роста, что даже самый высокий индеец доставал им только до колен. Их волосы ниспадали на плечи, а лица были безбороды.
8. Некоторые из них носили шкуры животных, другие ходили полностью обнажёнными. Продвигаясь по побережью, они опустошали страну – ведь каждый из них съедал за раз больше, чем могли съесть 50 человек!
9. На одной из глинобитных табличек древнего Вавилона говорится, что все астрономические знания жрецы Вавилонского государства получили от живших в Южной Азии великанов ростом свыше 4 метров.
10. Ибн Фадлан, арабский путешественник, живший тысячу лет назад, видел шестиметровый скелет человека, который ему показали подданные хазарского царя. Скелет того же размера, будучи в Швейцарии в музее города Люцерна, видели русские писатели-классики Тургенев и Короленко. Им рассказали, будто эти громадные кости были обнаружены в 1577 году в горной пещере врачом Феликсом Платнером.
11. Только четырёх- или шестиметровые гиганты были не самые гигантские. Завоёвывая Америку, испанцы якобы обнаружили в одном из храмов ацтеков скелет ростом аж в 20 метров. Это уже масштаб исполинов. Испанцы послали его в подарок Папе Римскому. А некий Уитни, служивший в начале XIX века главным археологом при правительстве США, обследовал череп диаметром два метра. Его нашли в одной из шахт штата Огайо.
12. Очевидными свидетельствами существования великанов являются отпечатки их огромных стоп. Самый известный из них расположен в Южной Африке. Его нашёл местный фермер Стоффел Кётци в начале прошлого века. В почти вертикальную стенку на глубину примерно в 12 сантиметров впечатан «след левой ноги». Его длина – 1 метр 28 сантиметров. Есть мнение, что обладатель огромного роста наступил, когда порода была мягкой. Потом она застыла, превратилась в гранит и встала вертикально из-за геологических процессов.
13. Удивляет одно: почему гигантские человеческие кости не выставлены ни в одном музее мира? Единственный ответ, который дают некоторые учёные, – мол, специально попрятали уникальные находки, иначе теория эволюции Дарвина окончательно рухнула бы и пришлось бы менять взгляды на всю историю человечества и его появления на земле.
Почему ж мы обмельчали?
Доктор Карл Бом считает, что в далёком прошлом природные условия благоприятствовали усиленному росту человека, а потом они резко изменились, и люди «измельчали».
«Оптимальное генетическое развитие, – говорит Бом, – это когда всё заложенное в ДНК организма развивается полностью за счёт благоприятных атмосферных условий». По его мнению, до Всемирного потопа озоновый слой был гораздо толще, а после от него осталась лишь одна седьмая часть. Уменьшение озонового слоя привело к ослаблению защиты от солнечной радиации, что отразилось и на растениях, и на животных, и, естественно, на человеке.

1Oz-pnXaNPM 4hPqitdSEPo jmBLp31yKWY -lZkiPw-tCM S_J1uI1NZ6Y tni7osyJXas uuhSfjAeT_0

 

Если Вы нашли ошибку, пожалуйcта выделите ее и нажмите Shift + E или нажмите здесь чтобы информировать меня. Спасибо.

Электронная библиотека в Метро

Интересной новостью сегодня утром порадовала одна лента (Источник). На одной из станций метро в Румынии открылась «Электронная библиотека», выбираешь книжку, считываешь QR-Code и попадаешь на сайт с книгой.

«Библиотека начала свою работу 29 августа и закроется в конце октября. Совершенно бесплатно люди смогут получить доступ к 49 книгам и 10 аудиокнигам на румынском языке, доступных для скачивания на планшеты или мобильные телефоны.»

Выбор конечно не богатый, но мне нравится сама идея.

Картинки можно найти здесь.

Если Вы нашли ошибку, пожалуйcта выделите ее и нажмите Shift + E или нажмите здесь чтобы информировать меня. Спасибо.

[.NET] Отладочные инструменты .NET разработчика

Очень понравилась статья с habr, позволю себе взять ее «на память» практически без изменений.

Баги встречаются на двух этапах жизненного цикла кода: во время разработки и в продакшене. Часто ошибки, которые вылезают в течение 10-15 минут с момента написания кода, мы даже не считаем за баги – они просто часть процесса написания кода. А багами мы гораздо чаще называем проблемы, которые проявляются в продакшене или при тестировании кода, написанного несколько дней назад; вероятно потому, что их сложнее отловить (код уже успел подзабыться). В любом случае, если код не делает того, что должен, это баг и его нужно отловить и исправить.

4 столпа эффективной отладки

 

  • Правильные инструменты. Это то, чему посвящена статья. Но инструменты бесполезны без других трех.
  • Использование практик построения архитектуры и кода, отдающих предпочтение слабо связанным объектам и написанию того, что я называю Совершенно Очевидный Код – СОК (Really Obvious Code – ROC rocks!). Эти практики помогают находить баги и избегать внесения изменений, лишь добавляющих новые. И никогда не поздно перечитать Brian W. Kernighan and P. J. Plauger’s «The Elements of Programming Style» (Computing Mcgraw-Hill, 1978).
  • Использование TDD (разработки через тестирование). Если вы разрабатываете что-то кроме сильно связанного пользовательского интерфейса и не используете TDD – вы разработчик с одной рукой, связанной за спиной. Вы менее продуктивны, чем могли бы быть, и ваш код менее надежен, чем должен быть.
  • Методика отладки. Многие разработчики сразу переходят к шагу «разработка решения», что в результате редко приводит к исправлению бага, зато часто создает новые.

 

Методика отладки
  1. Опишите баг. Соберите всю информацию для полного описания симптомов бага, акцентируя внимание на том, когда симптомы проявляются, а когда – нет.
  2. Зафиксируйте баг. Опишите последовательность действий, которая всегда приводит к появлению бага. Так вы убедитесь, что правильно определили условия, приводящие к появлению симптомов бага. Проверьте, что симптомы не проявляются при других условиях.
  3. Локализуйте баг. Убедитесь, что вы можете описать, в чем именно истинная причина появления бага и что описание соотносится с шагами 1 и 2.
  4. Разработайте и примените решение. Определите, боретесь ли вы с истинной причиной бага или с его симптомами. Напишите код.
  5. Проверьте решение. Проверьте, что симптомы больше не проявляются при выполнении действий, описанных в шаге 2.
  6. Проведите регрессионное тестирование. Проверьте, что не появилось новых багов.
  7. Примените изменения. Перенесите изменения в продакшен.

Использование точек останова

Многие разработчики не знают всех возможностей отладки в Visual Studio, потому что отладка «и так работает». Например, хотя каждый VS-разработчик знаком с точками останова, многие не знают, что можно сделать в окне Breakpoints.

Чтобы открыть окно Breakpoins, выберите Debug | Windows | Breakpoints; в окне отобразится список всех установленных вами точек останова. Если вы не уверены, какая точка какой строке кода соответствует, просто кликните по ней двойным кликом и в редакторе откроется связанный с ней код.

Определившись с нужной точкой, вы можете управлять тем, что происходит, когда она срабатывает. Я видел разработчиков, которые проверяют одни и те же переменные раз за разом, поставив точку останова в цикле. По правому клику на точке останова, выбрав When Hit (условие срабатывания), вы можете задать сообщение, которое выводится в окно Intermediate при каждом ее срабатывании. В сообщение можно включать некоторые константы: например, используя $Caller, можно вывести имя метода, вызвавшего код, содержащий точку останова. Также можно включить любые переменные, заключив их в фигурные скобки: например, {Me.NameTextBox.Text} в сообщении выведет значение поля Text.

Другая возможность диалога When Hit позволяет задавать, должно ли останавливаться выполнение программы на точке останова. Если выбрать остановку, то вы увидите каждое сообщение в момент его создания; в противном случае вы сможете просмотреть все сообщения после выполнения программы.

Если вы хотите остановить выполнение только при определенном условии, вы можете выбрать опции Condition или Hit Count. Опция Condition позволяет задать логическое условие, при котором произойдет остановка (например, Position > 30). Также можно выполнить остановку, если одна из переменных изменилась с момента последней остановки. Опция Hit Count прерывает выполнение только если точка останова сработала в n-й раз (или каждые n раз). Это особенно полезно, когда вам нужно остановиться где-то в конце цикла.

Между прочим, мой опыт говорит, что если в какой-то части приложения возникли проблемы, они продолжат там возникать. Если ваш опыт говорит о том же, вам понравятся дополнительные возможности Visual Studio 2010. Вы можете дать точкам останова названия, чтобы не забыть, для чего нужна каждая из них, и экспортировать их в XML-файл. В следующий раз, когда они вам понадобятся, вы можете импортировать их и начать отладку. Импорт/экспорт можно сделать с помощью тулбара вверху окна Breakpoints.

Показ и пропуск кода

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

В любой версии Visual Studio, в пункте Debug | General диалога настроек вы можете выбрать опцию Just My Code и перестать видеть код, который вы не писали. Если впоследствии вам понадобится это отключить (например, если где-то в сгенерированном коде возникает исключение), вы можете это сделать, выбрав Options and Settings в меню Debug (этот пункт есть только в VS2010 – прим. перев).

Если же вы устали ходить по какой-то части вашего кода, вы можете использовать один из двух атрибутов. Поставьте на метод атрибут DebuggerHidden и вы никогда не попадете в этот метод. Если же поставить атрибут DebuggerNonUserCode, вы не будете в него попадать при включенной опции Just My Code и будете при выключенной. Я рекомендую вам использовать второй способ.

С другой стороны, если ошибка возникает где-то в коде Microsoft .NET Framework, вам может понадобится пройти не только по сгенерированному коду, но и по коду классов фрэймворка. И вы можете это сделать! Во-первых, убедитесь, что отключена опция Just My Code. Затем в диалоге Options and Settings в разделе Symbols выберите Microsoft Symbol Server (в VS 2010) или задайте путь к символам какhttp://referencesource.microsoft.com/symbols (в VS2008). Это позволит вам загрузить символы, которые поддерживают хождение по коду классов .NET. Однако вам еще нужно их загрузить. В VS2010 вы можете кликнуть кнопку Load All Symbols, но нужно набраться терпения на время скачивания.

Чтобы выбрать конкретную сборку (или если вы используете VS2008), в режиме остановки процесса отладки откройте окно Modules и в списке DLL, загруженных вашим приложением, кликните правым кликом на нужной DLL и выберите Load Modules, чтобы загрузить символы для этой DLL. Конечно, подождать всё равно придется, но уже не так долго.

Я один из тех, кто пишет в свойствах полезный код и хочет иметь возможность пошагово их отладить. Начиная с VS2008SP1, появилась опция (Step over properties and operators), выключающая пошаговую отладку свойств и операторов. И в VS2010 она по умолчанию включена, так что вам может понадобиться ее выключить.

Визуализация данных

Как ни странно, множество разработчиков не знакомы с визуализаторами данных в Visual Studio. Если в режиме остановки навести мышку на переменную, всплывет подсказка со значением этой переменной. Также может появиться значок с лупой – клик по нему откроет значение переменной в визуализаторе по умолчанию. Если рядом с иконкой появляется стрелка выпадающего списка, клик по стрелке покажет другие визуализаторы для этого типа данных. Например, для строковой переменной будут показаны текстовый, XML и HTML визуализаторы. Если вы храните в строке HTML, HTML-визуализатор позволит понять, как это будет выглядеть в браузере.

Визуализаторы вы можете также использовать в окнах Watch, Autos и Locals, но если вы смотрите какую-то переменную очень часто, вы можете нажать на канцелярскую кнопку в конце всплывающей подсказки, чтобы «пригвоздить» ее на этом месте. Тогда в следующий раз, когда вы будете просматривать эту часть кода, подсказка всплывет автоматически.

Кстати о подсказках – вы можете с их помощью менять значение переменной. В VS2010 даже более того: подсказку можно заставить висеть в окне, существовать всё время сеанса отладки, и даже после его окончания она будет отображать значение переменной из последнего сеанса. Однако, самые крутые инструменты (Debugger Canvas и IntelliTrace) доступны только в VS2010 Ultimate Edition.

Только в VS2010 Ultimate Edition

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

Когда срабатывает точка останова, вам нужно понять, как вы здесь оказались. Можно использовать окно Call Stack, но вы не увидите, что происходило на более ранних этапах (как вариант, можно поставить кучу точек останова и проходить их последовательно, отслеживая переменные).

Если Debugger Canvas позволяет смотреть «через модули», то IntelliTrace – «через время», что дает понимание того, как вы попали в данную точку останова. IntelliTrace собирает и показывает отладочную информацию, которая была доступна в предыдущие моменты времени сеанса отладки.

Еще лучше Debugger Canvas и IntelliTrace работают в связке: в Debugger Canvas есть опция, позволяющая видеть логи IntelliTrace рядом с кодом.

Внешние инструменты

Visual Studio – не единственный инструмент отладки, есть сколько угодно внешних и сторонних инструментов, которые вы можете добавить в копилку. Я здесь остановлюсь только на некоторых бесплатных.

Не все внешние инструменты сделаны сторонними производителями. Если вы пишете службы Windows, то знаете, что отлаживать их непростое занятие. Хотя вы и можете подключиться к ним для отладки, к этому времени код OnStart и инициализация уже выполнится. Если баг не дает сервису запуститься, вам остается только гадать, что же пошло не так, вместо того чтобы собрать информацию для описания проблемы.

В подобной ситуации вы можете настроить Just-in-Time (JIT) отладку и автозапуск – сеанс отладки начнется, когда служба запустится или когда возникнет ошибка. Но чтобы это сделать, вам нужно воспользоваться внешними инструментами.

Так как настройка JIT-отладки выходит за рамки данной статьи, вы можете обратиться к соответствующейстатье в MSDN. Эта статья советует использовать Global Flags Editor (gflags.exe); на случай, если вы не можете его найти, описывается, как подправить реестр, чтобы включить JIT-отладку. Однако вам придется научиться пользоваться WinDbg.

WinDbg: за пределами отладчика Visual Studio

Если вам интересна отладка глубже исходного кода, Microsoft .NET Framework включает в себя несколько прекрасных инструментов.
Вот несколько из них:

  • Windows Debugger (WinDbg.exe)
  • SOS Debugging Extension (SOS.dll, которая может быть использована в консоли Visual Studio или с WinDbg.exe)
  • Assemble Binding Log Viewer (Fuslogvw.exe, который я обсуждал в блоге .NET Tips)

Если вы не использовали раньше WinDbg, это не так страшно, как может показаться – WinDbg имеет GUI (в отличие от консольных инструментов типа NTSD, KD и CBD) и может загружать PDB-файлы с отладочными символами для вашего приложения (просто убедитесь, что вы скомпилировали ваше приложение в Debug-режиме и файл символов гарантированно подходит). Вдобавок к SOS, есть еще несколько других расширений WinDbg для выполнения типичных отладочных задач.
Однако, самый полезный инструмент для использования с WinDbg – это книга Mario Hewardt, Patrick Dussud «Advanced .NET Debugging» (Addison-Wesley Professional, 2009). Она не просто рассказывает, как использовать все эти инструменты, но делает это в контексте отлавливания типичных для .NET проблем.

Сторонние визуализаторы

Я уже говорил про визуализаторы Visual Studio, но есть еще множество сторонних. DotNetDan’s DataSet Visualizer – весьма чудесен, если вам нужно знать, что лежит в датасете (я упоминал его в блоге)

С того времени я уже обнаружил RightHand DataSet Visualizer и стал использовать его. Это MDI-приложение, которое позволяет открыть окно для каждой таблицы датасета. Кроме того, окно Relations показывает таблицы, связанные с текущей просматриваемой.

Грид, отображающий таблицу, не простой – вы можете перетащить колонку в прямоугольник вверху окна, чтобы группировать вашу таблицу по этой колонке. Также можно изменять данные в датасете и менять фильтр RowState, чтобы отображались только строки с определенным RowState (например, только удаленные). Еще можно смотреть (и менять) некоторые свойства датасета. И даже можно выгрузить датасет в XML-файл или загрузить тестовые данные из сохраненного ранее.

Следует отметить, что DotNetDan’s DataSet Visualizer быстрее загружает данные, так что я оставил его на случай, когда не нужна вся мощь RightHand.

Еще есть Web Visualizer для приложений ASP.NET. Этот визуализатор доступен на всплывающей подсказке любого объекта страницы ASP.NET (включая Me и this в коде ASP.NET)

С помощью Web визуализатора можно смотреть любые данные коллекции Server Variables объекта Server и коллекции Forms объекта Request. Также можно посмотреть строку запроса браузера и содержимое объектов Session и Application. Однако, в случае Session и Application для любых объектов, кроме скалярных данных, вы увидите только название типа объекта.

Есть и другие визуализаторы, включая те, что позволяют смотреть Cache и LINQ-запросы к Entity Framework (EF), а также позволяющие увидеть SQL на выходе LINQ-запросов к EF. Печально только то, что нет единого каталога визуализаторов.

Не все, но многие можно найти через Visual Studio Extension Manager. В том числе, ASP.NET MVC Routing Visualizer. Если вы используете маршрутизацию в ASP.NET MVC или в простом ASP.NET, вам пригодится этот инструмент. Взаимодействие между правилами маршрутизации может выдавать неожиданные результаты («Почему я получаю эту страницу?»), и отладка этих правил может быть непростой. Визуализатор позволяет вам ввести URLы и посмотреть, как маршрутизатор их декодирует, включая информацию о том, какое правило используется для каждого URL. Чтобы использовать его в режиме останова, переключитесь на ваш файл global.asax и наведите курсор на RouteTable. Когдя появится всплывающая подсказка, промотайте до коллекции Routes и кликните на значок лупы.

Трассировка

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

Хотя в мире .NET для трассировки существует множество пакетов, я использую log4net. Среди прочих возможностей, log4net позволяет мне встроить в код отладочные сообщения и затем включать или отключать их во время работы без необходимости пересборки приложения. Одно замечание: log4net – очень гибкий инструмент и возможно больше, чем это требуется вам.

Когда дело доходит до чтения полученных логов, я использую Log Parser Lizard от Lizard Labs. В бесплатной версии некоторые возможности ограничены (цена платной – около 25$), однако мне они ни разу не понадобились. Log Parser Lizard использует SQL-подобный синтаксис для построения запросов к логам (включая файлы формата CSV и XML) и прямо из коробки понимает форматы логов IIS, событий Windows и log4net. Результаты отображаются в таблице, что делает его похожим на Server Explorer, с которым мне очень нравится работать.

Заключение

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

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

Если Вы нашли ошибку, пожалуйcта выделите ее и нажмите Shift + E или нажмите здесь чтобы информировать меня. Спасибо.

Искусство СПАМа

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

Сегодня ночью получил письмо, которое не жалко про пиарить

Если Вы нашли ошибку, пожалуйcта выделите ее и нажмите Shift + E или нажмите здесь чтобы информировать меня. Спасибо.