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

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

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

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

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

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

Каждый решает проблему обучения по-своему. Кто-то читает много литературы, кто-то старается поскорее перейти к практике и разбираться по ходу дела, кто-то пытается объяснять друзьям всё, что сам изучает. А мы решили совместить эти подходы. Итак, в этом курсе статей мы будем шаг за шагом демонстрировать, как пишется простая операционная система. Статьи будут носить обзорный характер, то есть в них не будет исчерпывающих теоретических сведений, однако мы будем всегда стараться предоставить ссылки на хорошие теоретические материалы и ответить на все возникающие вопросы. Чёткого плана у нас нет, так что многие важные решения будут приниматься по ходу дела, с учётом ваших отзывов.

Недавно компания Samsung представила новую мобильную платформу Bada и выпустила смартфон на этой платформе, Samsung Wave. Для разработчика смысл ее в том, что она предоставляет некий стандартный набор API поверх системы на основе GNU/Linux или собственной проприетарной ОС.

В первой части статьи рассказано, с чего начать, сделан обзор Bada SDK, описаны его особенности, подводные камни, варианты решения проблем, — все основано целиком на собственном опыте. Во второй части будет рассказано про упаковку приложения (т.н. deployment), магазин Samsung Apps, продажу приложения на Bada с авторскими замечаниями и советами.

Желающим поиграться с Bada: писать код придется на C/C++, без сбора мусора и прочих благ цивилизации. Если вас это не пугает, прошу под кат.

В проекте для iPhone столкнулся с необходимостью парсинга большого количества xml ответов от сервера. Хотел бы поделиться своим решением парсинга XML в NSDictionary.

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

Большая часть программ для iPhone и iPod touch поддерживают только портретную ориентацию. Многие разработчики даже не задумывались о том, чтобы добавить ландшафтную (альбомную) ориентацию там, где она действительно нужна. Не исключение и компания Apple, которая в iPhone OS 2.x подавала не самые лучшие примеры, не реализовывая поддержку ландшафтной (альбомной) ориентации в важных системных программах (в iPhone OS 3.x компания исправила свою ошибку).

С приходом iPad ситуация изменилась. Компания Apple обязала всех разработчиков поддерживать все ориентации устройства в программах для iPad. Естественно, могут быть исключения, например, игры. Но программы, которые не имеют жёсткой привязки (функциональной) к ориентации, должны быть дружелюбны к пользователю в любом положении устройства.

С простыми интерфейсами сложностей никаких нет. Объектам класса UIView задаётся необходимое свойство autoresizingMask, которое описывает изменение фрейма. К сложным интерфейсами такой метод уже не подходит.