Как разработать алгоритм, решающий сложную задачу? Многие считают, что для этого нужно «испытать озарение», что процесс этот не вполне рационален и зависит от творческой силы или таланта.

На самом деле решение любой задачи сводится к сбору информации о наблюдаемом объекте. Причем этот принцип применим как для решения самых сложных научно-исследовательских задач, так и для решения прикладных задач. Работа изобретателя напоминает не столько работу волшебника, сколько путешествие первооткрывателя по неизведанной территории. Главное качество хорошего изобретателя – умение собирать информацию.

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

Как известно, эти два продукта прекрасно уживаются вместе. Что удивительно — многие об этом не знают. Они давятся, плюются, но пишут код в Flash CS 5.
Данная статья рассказывает, как скрестить эти два продукта и как побороть мелкие неприятности в процессе.

Зачем нам Flash Builder, если есть Flash?
Ответ достаточно очевиден:
1. Нормальный Debug (condition breakpoints и прочие прелести)
2. Нормальный редактор кода с хоть каким-то, но рефакторингом
3. Version control
4. Интеграция с багтрэкерами
5. Другие вкусности Eclipse

Проблемы:
1. Абсолютные пути
2. Version control
3. Flex library projects и их подключение

Под катом описание мягкого способа создания проекта, при котором не будет проблем ни с svn, ни с абсолютными путями.

Довольно часто я наступаю на одни и те же грабли. Стараясь выполнить какой-нибудь проект побыстрее, я с головой ухожу в реализацию необходимой функциональности. А через неделю, мне на глаза обязательно попадается описание библиотеки, фреймворка или плагина, воспользовавшись которыми, я мог бы выполнить свою часть работы в разы быстрее. В общем, сейчас я стараюсь быть в курсе готовых решений в интересующих меня областях. В последнее время мне часто приходится работать с javascript и поэтому, сейчас я уделяю особое внимание библиотеке jQuery и ее плагинам. Должен сказать, что упускать из виду такое разнообразие готовых решений просто нельзя. Данная статья сделана на основе обзора «50 Awesome New jQuery Plugins», который я прочитал пару дней назад.

[FF D8]

Вам когда-нибудь хотелось узнать как устроен jpg-файл? Сейчас разберемся! Прогревайте ваш любимый компилятор и hex-редактор, будем декодировать это:

Специально взял рисунок поменьше. Это знакомый, но сильно пережатый favicon Гугла:

Последующее описание упрощено, и приведенная информация не полная, но зато потом будет легко понять спецификацию.

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

[FF D8] — маркер начала. Он всегда находится в начале всех jpg-файлов.

Следом идут байты [FF FE]. Это маркер, означающий начало секции с комментарием. Следующие 2 байта [00 04] — длина секции (включая эти 2 байта). Значит в следующих двух [3A 29] — сам комментарий. Это коды символов ":" и ")", т.е. обычного смайлика. Вы можете увидеть его в первой строке правой части hex-редактора.

Задача

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

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

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

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

Этот материал продолжает серию ежемесячных обзоров свежих статей по теме интерфейсов, новых инструментов и коллекций паттернов, интересных кейсов и исторических рассказов. Предыдущие материалы: апрель, май-июнь.