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

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

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

Приложение не отвечает?!

Многие из тех, кто программирует WPF-приложения, наверное тысячи раз писали конструкцию вида:

{Binding Items}

Если получение элементов коллекции Items выполняется в основном потоке приложения и занимает некоторое время — мы получаем «мертвый» пользовательский интерфейс. Приложение некоторое время не будет отрисовывать изменения состояния и реагировать на пользовательский ввод.

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

На волне повышенного внимания к мобильному софту, и в частности к App Store, мы тоже решили попробовать свои силы в этой хаотичной, на первый взгляд, массе. iPhone есть, MacBook есть, остается только выбрать что написать. Требования простые: это должно быть просто, это не должно занять много времени и это должно быть дешево. И еще очень хотелось написать такое, что и самим пригодится. Но все пошло не совсем так, как мы предполагали.

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

Сейчас часто пишут про хэндгам. Это такая бесполезная штучка из которой можно лепить, как из пластилина, с которой можно играть, как с каучуковым шариком, а если по ней резко ударить, то она расколется, как стеклянная. Правда «осколки» эти можно снова слепить вместе. Звучит привлекательно, но платить деньги за такую игрушку всё равно не хочется.

По просьбе гражданина dio нарисованы 25 иконок типов файлов в размерах 64х64, 48х48, 32х32 и 16х16. Иконки распространяются на условиях лицензии CC BY-ND.
Этот сет является дополнением к первому и второму бесплатным наборам.
Скачать иконки можно здесь

Закончил перевод четвертой главы книги о Blender Game Engine «Blender GameKit 2»

b3d.mezon.ru/index.php/Blender_GameKit_2/Tube_Cleaner

В главе описывается процесс создания игры в стиле First Person Shooter. Для выстрелов и поведения противников при попадании используется связка элементов BGE и кривых анимации Blender.

Описываемые методики являются универсальными и пригодятся при прототипировании игр любого жанра.

Перед освоением этой главы крайне рекомендую прочитать 3-ю главу книги описывающую основы Blender Game Engine.

P.s.
Предлагаю всем желающим поучаствовать в адаптации книги под Blender 2.5. Нужно будет выполнить уроки в Blender 2.5 и сделать скриншоты, аналогичные имеющимся.
Всех заинтересованных просьба писать мне в личку.

Как только ЖЖ позволил установить код Google Analytics на страницы дневника, я, конечно, сразу включил себе счетчик. Очень интересное ощущение — как будто рассеялся туман войны, стало видно, откуда на мой блог приходят посетители и что их интересует (за это мы и любим веб-аналитику, правда же?).

Один из самых интересных отчетов по сайту, на которые я обращаю внимание — “Ключевые слова”. Это запросы из поисковых систем, по которым нашли сайт: некоторые из них просто забавные, другие могут помочь понять нужды пользователей и придумать, о чем написать. Словом, отчет весьма полезный.

В один прекрасный момент я обнаружил

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

Иногда случается, что стройную и продуманную систему юнит-тестов душит сильная связность компонентов — особенно этим грешит legacy код, изначально не предназначенный для тестирования. Рефакторинг, конечно, спасает — но не всегда можно рефакторить. Одной из проблем, возникающих при создании юнит-тестов может стать использование static методов или non-virtual методов, которые должны быть перегружены для успешного написания тестов. Поможет в этом проект от Microsoft Research — Moles.

«Воровство доменов», а точнее, несанкционировнные смены NS-серверов, неправильные регистрации реселлерами, просто ошибки при регистрации — продолжаются. Тема не новая, но, как показывает практика — год из года не теряет своей актуальности.
Постарался собрать в одном месте все советы по правильной регистрации доменов. Заодно — вспомнил несколько мифов о доменах.
Даже если Вы знаете о доменах больше меня, пожалуйста, посмотрите статью — сделаем вместе «Наиболее полное руководство», статья ориентирована на новичков.
Где и как регистрировать домены? Что делать, если домен уже зарегистрирован, но есть сомнения в правильсти его регистрации?

...Skype — это дьявольски хитрая программа, написанная бесспорно талантливыми людьми..._{Крис Касперски}

Доброго времени суток!

Skype сейчас я встречаю чаще на компьютерах чем другие IM клиенты, мне он практически заменил icq, вся рабочая переписка ведется в skype, но речь пойдет не о том, что лучше или популярней. Часто бывает так, что участвуешь сразу в нескольких чатах где количество участников превышает 10, что собственно и приводит к тому, что на рабочем столе и в трее постоянно обновляется количество новых сообщений, а также уведомления в виде всплывающих сообщений, а теперь представьте что у вас 3 окна чата с друзьями, 1 с вашим боссом, другой с девушкой — все это в сумме начинает запутывать, отвлекать и порой раздражать. Хотелось бы расставить приоритеты…

Раньше я чаще всего настраивал «политику» уведомлений только через глобальные настройки программы
Случилось так, что я узнал, что в каждом окне чата skype возможно использование команд, например /alertsoff отключит уведомления для конкретного окна чата, соответственно /alertson включит их обратно.
Поискав немного я наткнулся на некое how-to, оказывается у skype чата довольно много текстовых команд, подобие IRC команд. Далее я постарался попробовать все возможные из них на двух имеющихся у меня платформах, как оказалось не все и не везде работает… Прошу под кат.

Наткнулся на Stackoverflow.com на интересный топик с вопросом о новом в программистском жаргоне. Предлагаю здесь подборку наиболее интересных выражений.

Египетские операторные скобки

if (a == b) {<br>  printf("hello");<br>}<br><br>

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

Проблема

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

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

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

Как то вечером, ожидая загрузку любимых LOST и Breaking Bad, захотелось прогуляться по теплому вечернему Минску в сторону парка Горького. Но вот незадача, примерное время скачивания торрента прыгает то вверх, то вниз, объективный прогноз дождаться явно не получится.
Тут и пришла в голову, на мой взгляд, неплохая идея — почему бы не сделать уведомление о скачавшемся торренте по смске? Можно тогда вообще не заморачиваться томительным ожиданием и делать свои дела. :)

Вот что из этого получилось…

Одно из приемуществ всеобщего удешевления аппаратуры и интернета в том, что сбор информации из разных источников в интернете почти ничего не стоит и может производиться без особых проблем. Задача получения и обработки больших объемов данных является коммерчески превлекательной ввиду спроса на считывание («скрейпинг») веб-сайтов со стороны заказчиков (обычно это описывается термином ‘social media analysis’, т.е. анализ социальных медиа). Ну и в принципе это достаточно интересно – по крайней мере по сравнению с рутинной разработкой сайтов, отчетов, и т.д.

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

Добрый день, друзья.

Сегодня я хочу поделиться своим опытом внедрения авторизации по openID на своем книжном сайте «Мои книги». Статья рассчитана на начинающих, поэтому вряд ли заинтересует тех, кто уже знает все нюансы этой технологии. Основная ее цель – ответить на вопрос: «да, это удобно, но как же мне сделать такое в моем проекте?!!»

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

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

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

На диаграмме слева отображена статистика по антивирусным защитам, установленным на компьютерах пользователей одновременно с заражением TDSS.