Вступительное слово

Данная статья расчитана на тех, кто уже хотя бы немного знаком с языками С# и F#. В любом случае, я старался сделать код как можно более читабельным и давать описание каждому фрагменту. Ознакомиться с языком F# можно в следующих статьях:

• Введение в F#, или полезное о бесполезном
• F#: Hello, World!
• MSDN: Первое знакомство с F#

На Хабре уже много писали общих слов о языке F# — его истории, происхождении, особенностях. Не хочется повторяться, поэтому предлагаю сразу перейти к делу. Итак, план действий следующий:

1. Построение множества Мандельброта;
2. Визуализация результатов;
3. Интеграция с C# и не только с ним.

Итак, поехали.

Вступление

А зачем оно мне?

А почему бы и нет? К примеру, для общего развития, или просто для интереса, а впоследствии, может быть, для того, чтобы убедиться, что F# — не просто язык для ознакомления.

Постановка проблемы

Некоторое время назад по долгу службы работы, встал на обсуждение вопрос «А нужно ли делать на новом проекте авторизацию через сторонние сервисы?». Мозг, взбудораженный красивыми всплывающими окошками, виджетами и прочими украшательствами, призывно требующими «Войди через меня!», конечно же обеими руками был за, да и современные вебдванольные (а то и, тьфу тьфу, вебтринольные, быть может?) тенденции развития крупных порталов, как бы, намекают. Однако, я не зря сказал, что началось всё с обсуждения, ибо, где есть споры, там есть и камни преткновения. Такой камень мы нашли и здесь.

Предположим, на сайте имеется красивая панелька, как, например, у логинзы, или просто отдельные виджеты авторизации, например, через контакт, твиттер, фейсбук и иже с ними. Легко войти на сайт? Безусловно. Но при этом, если человек войдет сразу со всех этих аккаунтов (одновременно или нет, не суть), для системы это будут разные люди, а следовательно, клоны одного и того же человека, учётной записи которого, быть может, и вовсе нету на сайте.

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

Уверен, что всем разработчикам приложений на платформе Android знаком класс Log, позволяющий логировать различные события. По различным причинам, формат записи логов для каждого проекта может отличаться достаточно сильно — начиная от «AAA», «111111» и «I was here» до более-менее внятных — «Opening HTTP connection to habrahabr.ru». Под катом вы найдете пример функции, которая поможет навести порядок в логах.
Данный топик не претендует на оригинальность и универсальность. И поэтому, если в вашем проекте уже существует некий стандарт логирования событий, то смело проходите мимо — топик скорее ориентирован на начинающих разработчиков.

_{Предисловие переводчика.  «Костыль» PIE, позволяющий легко и уверенно обеспечить поддержку целого ряда свойств CSS3 во браузерах IE6, IE7 и IE8 (которые в этом смысле без «костыля» оказываются «хромыми» до убожества), давно заслужил горячую, страстную приязнь со стороны многих передовых сайтооформителей, и в этом качестве не раз на Хабрахабре упоминался (последний раз — 13 января 2011 г.). Я решил перевести нижеследующее, пускай и не новое, объявление (выход PIE 1.0 beta 3 состоялся 6 декабря 2010 г.) для того, чтобы в явном виде лишний раз донести до всех заинтересованных читателей весть о том, что в этот год PIE вступает обновлённым и улучшенным. Всем тем, кто впервые начал использовать PIE прошлой осенью или летом, настало время крепко призадуматься, во-первых, об апгрейде PIE (во имя ускорения работы сайтов), а во-вторых, об освоении новых, декабрьских свойств и возможностей PIE.}

Она подготавливалась долгое время, но вот третья бета PIE 1.0 наконец вышла! Этот выпуск содержит множество изменений; вот некоторые из крупных улучшений в нём:

• Скорость! — Крупнейшим и легкозаметнейшим улучшением в этом выпуске стала скорость. По итогам обширного профилирования были найдены наиболее медленные участки исполнения кода PIE, и многие из них подверглись оптимизации. Результаты ошеломляют: скорость PIE выросла до четырёх раз в сравнении со второй бетою, особенно заметно — в IE8. И это принесёт ускорение обработки страниц и вам, и читателям ваших сайтов!
   
• Ленивая инициализация — Даже с учётом всех улучшений скорости, если ваша страница весьма длинна, она может содержать сотни PIEфицированных элементов, которые суммарно приведут к заметной задержке. Однако есть шанс, что лишь немногие из них видны в окне просмотра изначально (после загрузки страницы), чего же тогда тратить время на обработку остальных элементов, прямо сейчас не видимых? Теперь вы можете задавать специальное свойство -pie-lazy-init: true в CSS, и тем самым откладывать инициализацию всех PIEфицированных элементов за пределами видимой области загруженной страницы. Они будут проинициализированы и отображены после того, как читатель до них допрокручивает страницу.
   
• PIE.js: отдельная версия на джаваскрипте — Теперь есть два способа использования PIE: традиционный (PIE.htc и behavior) и новый (отдельный джаваскриптовый файл PIE.js). Хотя указание файла .htc и свойства behavior останется рекомендуемым подходом, JS-версия позволяет употреблять PIE в некоторых таких ситуациях, в которых behavior не в состоянии сработать. Поглядите в документации по PIE.js подробности о том, когда и как вы можете пожелать прибегнуть к JS-версии.
   
• Работает с табличными элементами — Теперь применение PIE к элементам <table>, <th> и <td> приводит к корректной обработке и впредь не грозит бесконечным циклом.
   
• Работает с изображениями — Теперь вы можете использовать PIE для закругления уголков элементов <img>.
   
• -pie-png-fix — Теперь вы можете использовать PIE в качестве общего исправления альфа-прозрачности PNG для IE6, используя новое специальное CSS-свойство -pie-png-fix: true. Подробности изложены в документации по -pie-png-fix. Эту функциональность обеспечил Felix Gnass.
   
• Отключено в IE9 — Так как IE9 самостоятельно поддерживает множество тех же свойств и значений CSS3, что и PIE, и так как ещё не ясно, что IE9 будет поддерживать в окончательной версии, то на время PIE будет отключаться при работе в IE9; это временное решение будет пересмотрено по мере дальнейшего развития событий.
   
• position:fixed — Теперь PIE располагает свои элементы отображения корректно, когда применяется к элементам со свойством position:fixed (это никак не касается IE6, поскольку IE6 не поддерживает свойство position:fixed самостоятельно).
   
• Печать — Теперь PIE самостоятельно устраняет все свои элементы во время печати страницы. Помимо исключения целого ряда проблем с отображением, такое самоустранение также не пренебрегает пользовательскими настройками о непечатании фонов и обеспечивает экономию чернил.
   
• Множество других исправлений и улучшений — см. логи правок кода.

Скачайте PIE 1.0 beta 3 прямо сейчас!

В рамках «Недели разработки для Андроид» решил поделиться кое-чем из своего опыта.
Итак, за что мы любим эти маленькие шустрые гаджеты, живущие в наших карманах и сумках? Не ошибусь, если поставлю на первое место красивую разноцветную графику. В этом нет ничего постыдного — ведь даже мудрые вожди индейских племен готовы были на что угодно ради красивых стекляшек для своей скво.
Итак, нам просто до дрожи в руках хочется написать свою прекрасную шедевральную игру, готовую произвести революцию в умах геймеров. Вот только маленькая неприятность — попытка напрямую воспользоваться drawRGB() и иже с ними сразу обламывает все мечты, ибо подобным образом написанная игра сможет получить признание разве что в Эстонии, да и то если раунд закончится раньше, чем сядет батарейка.

Прелюдия

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

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

 

Компания Pluralsight, при поддержке Microsoft, делает прекрасное предложение для веб-разработчиков и предлагает бесплатный доступ к своему профессиональному видео-курсу обучения технологии ASP.NET MVC 3. Предложение ограничено по времени, курс будет свободно доступен только до 18 марта. Курс подготовлен на английском языке.



Курс состоит из следующих частей:

• введение: новый проект, шаблон MVC, маршрутизация, контроллеры, представления, создание действия;
• движок представлений Razor: преимущества Razor, создание простого представления, смешивание кода и разметки, модели и ViewData, HTML-хелперы, частичные представления, модель компоновки представления, код для автоматического запуска, конфигурация;
• контроллеры: глобальные фильтры действий, кэширование результатов вложенных действий, ViewBag, новые результаты действий, валидация запросов;
• модели: валидация в MVC3, аннотация данных, пользовательские атрибуты валидации, модели с поддержкой валидации, клиентская валидация, пользовательская клиентская валидация, удаленная валидация;
• NuGet: средство управления пакетами, зависимости пакетов, использование PowerShell, пользовательские пакеты;
• Dependency Injection: инъекции зависимостей, использование IDependencyResolver, инъекция в контроллерах, инъекция в представлениях, активаторы, расширяемость фильтров, расширяемость моделей.

Pluralsight делает весьма и весьма качественные видео-курсы, поэтому рекомендую всем не упустить возможность и ознакомиться с этим бесплатным предложением. Очень хороший шанс начать изучать ASP.NET MVC или узнать что нового было представлено в MVC3.

У нас в компании с незапамятных времен существует гласно-негласное правило о логировании входа в каждую функцию. И ладно бы это ограничивалось простой строчкой Logger.LogEntering() в их начале (хотя, наверное, тоже надоело бы), так еще и наш «замечательный» доморощенный логгер получать названия функций из которых он вызван не умеет, и как следствие, эта единственная строчка разрасталась до эпического Logger.Log(«Classname.FunctionName — Entering») or something like that.

Неудивительно, что под воздействием недавних топиков о Mono.Cecil и родилась задача автоматизации процесса.

На написание данной статьи меня подтолкнул топик HTML в PDF, правда по причине того, что он посвящен языку php, лично мне он был мало полезен, т.к. весь опыт работы с php у меня сводился в переводе нескольких скриптов на C#, поэтому я решил сделать небольшой обзор того, что доступно для работы с pdf по средствам языка C#.

Ко мне в список попало 7 библиотек, о которых я скажу несколько слов, а для самой популярной (судя по ответам на stackoverflow), я напишу, как с помощью неё сделать простейший документ. Сразу скажу, что это iTextSharp и работа с ней будет описана в конце статьи.

Еще в прошлом году на просторах Интернета у забугорных собратьев (а именно у Алекса Галузина) по геймдеву увидел замечательную книгу «How to Create a Map in 11 Days». Сразу появилась мысль о ее прочтении и переводе на русский язык.

Хоть в книге и идет речь о UDK и Maya она не привязана ни к каким движкам, а больше рассказывает о организации рабочего процесса и постановке задач при разработке игрового уровня.

В статье собраны всем известные методы и предельно извращенные. Эту статью я решил написать после недавнего прочтения поста в блоге Badass JavaScript и решил её дополнить своими находками.

Первый способ

Он всем известен — обфускация минимизаторами такими как JS Packer, JSmin, YUI Compressor, Closure compiler или можно просто пугуглить «JavaScript Obfuscator» и найдется ещё сто штук разных обфускаторов.
Они превращают существующий код

function MyClass(){
    this.foo = function(argument1, argument2){
        var addedArgs = parseInt(argument1)+parseInt(argument2);
        return addedArgs;
    }
    var anonymousInnerFunction = function(){
        // do stuff here!
    }
}

В какой-то такой вид:

function MyClass(){this.foo=function(c,b){var d=parseInt(c)+parseInt(b);return d};var a=function(){}};

Или такой:

var _0xd799=["\x66\x6F\x6F"];function MyClass(){this[_0xd799[0]]=function (_0xefcax2,_0xefcax3){var _0xefcax4=parseInt(_0xefcax2)+parseInt(_0xefcax3);return _0xefcax4;} ;var _0xefcax5=function (){} ;} ;

Или вот такой:

eval(function(p,a,c,k,e,d){e=function(c){return c};if(!''.replace(/^/,String)){while(c--){d[c]=k[c]||c}k=[function(e){return d[e]}];e=function(){return'\\w+'};c=1};while(c--){if(k[c]){p=p.replace(new RegExp('\\b'+e(c)+'\\b','g'),k[c])}}return p}('4 0="3 5!";9 2(1){6(1+"\\7"+0)}2("8");',10,10,'a|msg|MsgBox|Hello|var|World|alert|n|OK|function'.split('|'),0,{}))

Но ничего не стоит его восстановить с помощью jsbeautifier.org либо просто убрать eval и получить исходный код, многое потеряем, но смысл кода восстановим. Ну и с первого взгляда мы видим, что перед нами JavaScript.

Все это были цветочки под катом жесткие методы обфускации.

Предисловие

Хабралюди проявили некоторый интерес к Unity, поэтому открываю этим постом цикл туториалов, освещающих основные моменты работы с объектом (цикл неопределённой пока длительности — если кому окажется полезным продолжу).

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

Существует великое множество файловых систем. Это и файловые системы для носителей информации (FAT*, NTFS, ext* и т.д.), и сетевые файловые системы (NFS, CIFS и т.д.), и виртуальные файловые системы, и великое множество других. А появлялась ли у тебя, %habrauser%, потребность в своей, еще несуществующей файловой системе? О том, как ее сделать для ОС Windows на managed-коде (.net), и пойдет речь.

Попробовал сделать перевод вчерашнего топика-ссылки на хабре. Заранее извиняюсь, если формулировки покажутся вам кривыми, я с удовольствием приму конструктивную критику. Поехали…

Мне кажется правильным начать этот блог с темы, которая вдохновила меня в первую очередь. Не так давно я наткнулся на статью Jamey Pittman «Pac-Man Dossier», в которой приводилось очень детальное описание механики игры Pac-Man. Она показалась мне очень интересной, поэтому этот сайт — попытка собрать такую же детальную информацию об остальных играх. Но в дань уважения я все же начну с Pac-Man, а в частности, с описания алгоритма поведения привидений. Это очень интересная тема и, надеюсь, мое объяснение будет немного более понятным и доступным, чем у Джейми, потому что я сосредоточусь лишь на поведении.

Об игре:

«В то время все доступные игры были очень жестокими — игры о войне и космических захватчиках. Не было ни одной игры для всех сразу, а особенно, которые понравились бы девушкам. Я хотел придумать «комическую» игру, которой могли бы наслаждаться даже девушки»
— Toru Iwatani, создатель Pac-Man

Первый раз достаточно близко я познакомился с тестированием лет 5-6 назад, как раз начало моей карьеры. Тогда, я помню, мне рассказывали про покрытие кода тестами. Причем никаких Unit тестов меня не просили писать, просто говорили: “вот видишь if с тремя условиями, который ты написал, ты должен проверить все эти три условия”. Подразумевалось, что я, после того как напишу код, должен его проанализировать, и полностью протестировать обычным проходом по интерфейсу приложения. Как вам? Со временем знания в тестировании у меня немного выросли, я немного научился писать тесты. Я до сих пор не видел и не участвовал ни в одном живом проекте, написанным при помощи Test Driven Development (TDD) подхода. Основа моих знаний была в подглядывании того, как делают это коллеги в предыдущей моей конторе, чтении статей (например, у Алесандра Бындю была отличная статья “TDD для начинающих. Ответы на популярные вопросы”), просмотра пару сринкастов. Я решил покончить с безграмотностью и проникнуться темой, для этого я сел за прочтение книги The art of Unit Testing with Examples in .NET. Притом, что в текущей конторе? можно сказать, что тесты пишу только я для своего кода. Нужно быть образцом.

Было обычное серое утро, начало рабочей недели, вдруг, эфир командного чата сотряс наш именинник Янис, он же jamez:

On 11/1/10, at 12:27 PM, Янчик М. wrote:
> эй пипл, есть тема: http://habrahabr.ru/blogs/DIY/107313/

Расстояние небольшое, на вскидку, километров 200 в одну сторону. Эта затея вызвала большой интерес со стороны участников беседы. И сразу же выявились еще 3 человека, готовых к приключениям: justass, Lifz и popcha, которые и составили jamez'у компанию, позднее подтянулся JohnieWalker который нас штабил.

Возможно, многие из читателей задавались вопросом, как людям удаётся собирать кубик Рубика 3×3 за 7 секунд. Если даже предположить, что рекордсмену сильно повезло, то таблица мирового рейтинга по среднему из пяти результатов уже не оставляет сомнений: если больше 80 человек в среднем укладываются в 12 секунд, очевидно они что-то знают. В этом кратком обзоре я постараюсь приоткрыть секреты скоростной сборки. Сразу оговорюсь, что после прочтения этой статьи вы не станете чемпионами: здесь приведены только основные моменты и ссылки на более подробную информацию. Кроме того, даже после изучения метода полностью вам потребуются долгие тренировки для достижения хороших результатов. Зато вы получите неплохое представление о том, как это делается, и при желании будете знать, куда двигаться дальше. Я думаю, при достаточной усидчивости после нескольких месяцев тренировок многие смогут достичь среднего результата в районе 30 секунд.

Это двадцать шестая публикация в серии публикаций о VS 2010 и .NET 4.

Сегодняшняя публикация рассматривает некоторые полезные советы по отладке которые вы можете применять в Visual Studio. Мой друг Скот Кэйт (Scott Cate) (который опубликовал в блоге дюжину великолепных советов и трюков по VS) недавно обратил мое внимание на несколько хороших советов о которых не знает много разработчиков использующих Visual Studio (даже при том, что многие из них работают с ней уже давно с более ранних версий).

Качественная документация – неотъемлемая часть успешного программного продукта. Создание полного и понятного описания всех функций и возможностей программы и программного компонента требует немало сил и терпения. В данной статье я рассмотрю некоторые практические аспекты создания документации для .NET компонентов.

Предположим, что у нас готова или почти готова некоторая .NET библиотека для разработчиков (они же конечные пользователи). API библиотеки безупречен, количество багов впечатляюще мало, да и вообще это не библиотека, а просто кладезь совершенного кода. Дело за малым – объяснить пользователям, как работать с этим замечательным продуктом.

Есть разные подходы к написанию документации. Некоторые команды предпочитают начинать создание документации в момент начала создания продукта. Другие откладывают написание мануалов на окончание работ. В некоторых командах документацию пишут специальные люди, которые ходят от разработчика к разработчику и от менеджера к менеджеру, аккумулируя знания о продукте. Во многих небольших командах таких специальных людей нет, а потому документацию часто пишет разработчик или разработчики. Кто-то использует сторонние средства вроде Help & Manual, в которых, как в заправском текстовом редакторе, можно создавать очень сложную верстку и на выходе получать документацию в многообразии форматов. Многие используют другой подход, широко пропагандируемый в последнее время – написание документации прямо в коде программы/библиотеки.