CustisWiki - Новые страницы [ru]

Практика разработки на Java (Дмитрий Завалишин на ADD-2010)

2010-12-24T17:20:10Z

StasFomin: /* Примечания */

Об удобстве иерархических структур данных (Андрей Майоров на ADD-2010)

2010-12-24T17:18:51Z

StasFomin: /* Примечания */

На пороге дополненной реальности: к чему готовиться разработчикам (Андрей Бибичев на ADD-2010)

2010-12-24T17:15:07Z

StasFomin:

Лицензии для Open-Source (Николай Мациевский на ADD-2010)

2010-12-24T17:13:38Z

StasFomin:

Как начать разрабатывать для iPhone (Никита Фролов на ADD-2010)

2010-12-24T15:01:43Z

StasFomin: /* Примечания */

Искусственный интеллект в играх (Елена Сагалаева на ADD-2010)

2010-12-24T14:59:09Z

StasFomin: /* Примечания */

Адаптивная архитектура (Олег Аксенов на ADD-2010)

2010-12-24T14:53:29Z

StasFomin: /* Примечания */

IBM Rational Jazz (Дмитрий Ханецкий на ADD-2010)

2010-12-24T14:50:45Z

StasFomin: /* Примечание */

HTML5, CSS3 и новый Internet Explorer 9 (Михаил Черномордиков на ADD-2010)

2010-12-24T14:48:58Z

StasFomin:

C++0x (Елена Сагалаева на ADD-2010)

2010-12-24T14:45:26Z

StasFomin: /* Примечания */

Как прекратить писать (Андрей Аксенов на ADD-2010)

2010-12-24T14:35:13Z

StasFomin:

Обзор Agile (Никита Филиппов на AgileDays-2009)

2010-12-22T15:07:02Z

VitaliyFilippov:

Платформа 2011: Отчет Гаврилова Дениса

2010-11-25T14:05:53Z

BenderBot: 1 версия

Моя страница на Круге

Конференция «Платформа 2011», посвященная продуктам и технологиям Microsoft.

Проходила 17-18 ноября в Москве, в Центре Международной Торговли на Красной Пресне.

Сайт мероприятия http://www.msplatforma.ru

Вакансия руководителя группы

2010-11-15T08:19:53Z

StasFomin:

В направлении «Финансовые институты» компании CustIS открыта вакансия руководителя группы. Проектная группа занимается разработкой модуля автоматизированной банковской системы для одного из крупнейших банков России.

Agile Learning: Программируем и тестируем. Людей.

2010-11-09T00:39:20Z

BenderBot: 1 версия

SECR-2010: Отчет Белобородова Дмитрия

2010-11-03T14:03:11Z

BenderBot: 1 версия

Agile Learning: Эффективные инструменты

2010-11-02T11:53:39Z

BenderBot: 1 версия

Все блюда для интранета из MediaWiki

2010-10-28T11:51:38Z

BenderBot: 1 версия

Slide Show

Warning: legacy <slide> parser hook used, change it to <slideshow> please

Заголовок: Все блюда для интранета из MediaWiki
Автор: Виталий Филиппов
Нижний колонтитул: Все блюда для интранета из MediaWiki
Дополнительный нижний колонтитул: Виталий Филиппов, 03:03, 29 октября 2010

UNTITLED

2010-10-25T15:38:58Z

81.19.66.77: Dummy article created for Simple Forms extension

Dummy article used by Extension:SimpleForms

Учет ценных бумаг - сделать сложное простым (Цепков на SECR-2010)

2010-10-19T12:23:57Z

VitaliyFilippov:

Доклад был сделан на банковской секции конференции SECR-2010

Презентация выложена на slideshare

Докладчик: Максим Цепков, главный архитектор компании CUSTIS (Заказные ИнформСистемы)

Название доклада: Учет ценных бумаг - сделать сложное простым (Securities Accounting - Make It Easy).

Вакансия ведущего разработчика .Net

2010-10-04T14:13:18Z

StasFomin:

В направлении «Торговые сети» компании CUSTIS открыта вакансия Ведущего разработчика C# в одну из проектных команд. Система (модуль «Модуль распределения товара») находится в стадии интенсивной разработки. Модуль будет представлять собой высоконагруженное трехзвенное line of business приложение, обеспечивающее движение товара в крупной розничной торговой сети в режиме 24х7. В решении применяются технологии Microsoft .NET (C# 3.0), СУБД ORACLE и ряд внутренних технологий компании.

Вакансия Team Lead (Java, Oracle)

2010-10-04T14:09:19Z

StasFomin:

В направлении «Финансовые Институты» компании CUSTIS открыта вакансия Team Lead в одну из проектных групп. Группа разрабатывает и развивает приложения, обеспечивающие бизнес-процессы в крупной финансовой организации. Приложения строятся в трехзвенной архитектуре с клиентскими интерфейсами в виде Web- или Swing-приложений. К приложениям предъявляются требования высокой надежности, эргономики и производительности.

Вакансия инженера-аналитика

2010-09-27T16:12:00Z

StasFomin:

Основные требования:

знание современных информационных технологий;
аккуратность и педантичность;
умение работать в команде;
опыт и желание общаться с клиентами компании и конечными пользователями;

желательны:
- опыт работы в IT-индустрии,
- знакомство с СУБД (SQL).

Предлагается участие в проекте разработки модуля направления «Торговые сети», включая:

тестирование;
техническую поддержку на этапе внедрения и сопровождения;
анализ требований заказчика;
написание постановок на доработку и развитие системы;
написание технической документации;
обучение конечных пользователей со стороны клиента (в зависимости от проекта).

Условия

Компенсация обсуждается индивидуально с каждым соискателем по результатам собеседования. Но в целом, наши зарплаты не ниже, и даже существенно выше рынка. Есть и медицинская страховка: поликлиники и стоматология. Уровень заработной платы адекватно отражает профессиональный и позиционный рост;
Работа в команде профессионалов: многие наши сотрудники являются признанными экспертами в индустрии, публикуются в СМИ, от бумажных до хабра, активно выступают практически на всех IT-конференциях, более того, мы сами организуем IT-конференции и открытые семинары. У нас давно выстроены Agile-процессы разработки (адаптированный SCRUM), сочетающие эффективность и гуманизм.
Комфортная работа: мы доверяем сотрудникам, и поэтому у нас нет жестких ограничений, таких как фиксации прихода-ухода, дресс-код, фильтрации интернет-трафика и т.п. Возможен гибкий график работы, и даже удаленная работа (по VPN). Мы не экономим на инструментах: компьютерах, софте, мебели и т.п. Например, стандарт по мониторам — качественный 24" (+ вспомогательный), по компьютерам — «Core i7 с SSD», и т.п.. Возможно совмещение работы с учебой на старших курсах.
Рост и развитие сотрудника: компания оплачивает участие сотрудников в конференциях и тренингах, поощряет профессиональную сертификацию. А внутри налажен процесс внутреннего обучения силами сотрудников.
Удобный офис в центре Москвы, в пятиминутной доступности от пяти станций метро: «Тургеневская», «Чистые пруды», «Сретенский бульвар», «Лубянка», «Китай-город». Для автовладельцев (и велосипедистов) есть охраняемая стоянка (платная), впрочем, можно бесплатно запарковаться в переулках.

Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».

Репликация: База Знаний «Заказных Информ Систем» → «Вакансия инженера-аналитика»

Вакансия ведущего разработчика Oracle

2010-09-27T16:09:03Z

StasFomin:

В подразделениях компании «Торговые сети» и «Финансовые институты» открыта вакансия ведущего разработчика Oracle.

Проектные команды «Торговых сетей» ведут разработку модулей ПО «Каталог товаров», «Финансовый», «Розничная торговля», «Общее квотирование», «Оптовые продажи» и других для ИС крупной торговой сети. Работа в рамках проектов включает в себя проектирование элементов системы, разработку базы данных, серверной бизнес-логики, пользовательских интерфейсов и механизмов межсистемной интеграции.

Проектные команды «Финансовых институтов» ведут разработку модулей автоматизированной банковской системы для нескольких крупных российских банков. Работа в рамках данных проектов включает в себя решение учетно-аналитических задач, сложных интеграционных задач, а так же задач оптимизации нагрузки потоков данных.

Проекты предусматривают применение технологической платформы на базе СУБД Oracle и ряда внутренних технологий компании.

Вакансия бизнес-аналитика

2010-09-27T16:04:45Z

StasFomin:

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

Работа над задачами потребует от Вас:

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

Ваша кандидатура особенно интересна нам, если Вы:

имеете опыт работы в банке или у поставщика IT-решений для банка;
владеете инструментальными средствами описания требований и бизнес-процессов;
ориентируетесь в современных технологиях и средствах разработки ПО.

Вакансия ведущего разработчика Java

2010-09-27T15:59:49Z

StasFomin:

В направлении «Финансовые Институты» компании CUSTIS открыта вакансия ведущего разработчика Java в одну из проектных групп. Группа разрабатывает и развивает приложения, обеспечивающие бизнес-процессы в крупной финансовой организации. Приложения строятся в трехзвенной архитектуре с клиентскими интерфейсами в виде Web- или Swing-приложений. К приложениям предъявляются требования высокой надежности, эргономики и производительности.

Вакансия системного аналитика

2010-09-27T15:48:52Z

StasFomin:

В направлении «Финансовые Институты» компании CUSTIS открыта вакансия cистемного аналитика в одну из проектных групп. Группа разрабатывает и развивает приложения, обеспечивающие бизнес-процессы в крупной финансовой организации. Приложения разрабатываются с использованием Java и Oracle.

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

Презентация-трансформер: S5 на MediaWiki/Слайды

2010-09-22T14:53:48Z

VitaliyFilippov: /* Слайд GnuPlot */

Золотая середина: открытые системы поддержки разработки/Аннотация

2010-09-10T07:20:44Z

BenderBot: 1 версия

Наша тема — системы поддержки разработки. Коллективная разработка всегда сталкивается с одними и теми же проблемами групповой работы - над кодом, документацией, тестами, ошибками и требованиями, корпоративными знаниями, и каждый решает эти проблемы по-своему. Кто-то увлекается изобретением систем собственной разработки ("изобретают велосипед"), кто-то идёт к вендорам, кто-то покупает платные специализированные узконаправленные системы.

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

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

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

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

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

В нашем докладе мы не просто расскажем об опыте интеграции («Talk is cheap, show me the code» © Линус Торвальдс), мы идем на большее, — мы публикуем в open-source полностью все используемые нами системы, с доработками и расширениями. Мы предлагаем сообществу совершенно бесплатно установить все это у себя, и возможно, присоединиться к развитию этого инструментального фреймворка.

Золотая середина: открытые системы поддержки разработки

2010-09-02T12:57:50Z

BenderBot: 1 версия

Любая коллективная разработка программного обеспечения сталкивается с одними и теми же проблемами:

групповая работа над кодом, документами;
учет проблем, ошибок, требований;
документирование, накопление и циркуляция (поиск, трансляция, агрегация) знаний компании;
организация правильного тестирования.

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

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

Да, полно разных классификаций функциональности, которую должны обеспечивать эти системы asset management, requirements management/tracking, bug management, issue management, customer support/help desk, knowledge base, XXX management — очень легко запутаться, лично мы придерживаемся очень простой классификации, разделяя системы в случае учета — по основному объекту учета:

Исходный код/артефакты разработки: Системы управления версиями, вебинтерфейс к репозиториями, системы полнотекстового поиска.
Проблемы/ответственность: системы трекинга проблем, системы управления задачами, системы баг-трекинга.
Знания: вики-системы, блоги-форумы, коллаборативное документирование.
Интеграция информационных потоков: RSS-агрегаторы, почта.

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

Мы считаем, что при выборе систем, важно смотреть на классификацию по следующим двум осям:

Интегрированность: Снизу этой оси системы решающие частные задачи — управление версиями, вебинтерфейс к управлению версиями, поиск, совместное редактирование текстов, учет проблем и т. п. Сверху — интегрированные «комбайны», где все связано со всем (статьи-задачи-проблемы код), и центром интеграции обычно является IDE-разработчика.

Важно понимать, что это «неоднозначная ось» — интегрированней, не всегда значит лучше! Что-то приобретается (юзабилити стандартных сценариев, например), но что-то выплескивается вместе с водой! Теряется гибкость и некоторые возможности, которые разработчики (или, что хуже, маркетологи) посчитали ненужными! А иногда падает и юзабилити, когда куча лишней функциональности занимает интерфейс, но не используется разработчиком. Интегрированность иногда означает «интегрированность в рамках Одной Операционной Системы и Технологического Стека Одной Компании». Особенно это печально, в случае закрытой, платной системы, когда нет никакой возможности, что-то исправить, изменить, срезать углы… И уповать на платную поддержку бессмысленно — обычно платная поддержка это аутсорсинговый колл-центр, и повлиять на функциональность продукта «в свою сторону» — практически невозможно.

Закрытость-Открытость: Да, имеется в виду именно закрытость или открытость исходного кода — именно этот фактор определяет, как развивается продукт, силами сообщества (в случае открытого кода), или исходя из внутренних инженерно-технологически-маркетинговых соображений. Вообще, «закрытость-открытость» очень сильно коррелирует с «платностью-бесплатностью», хотя есть и исключения (например, можно купить исходники Jira), но в любом случае, даже если исходники открыты, но продукт платный, его развитие определяется не сообществом — мало кто будет контрибъютить свои доработки, развивая чужой, платный продукт.

Кстати, все больше распространяется мнение, что открытость софта позитивно коррелирует с качеством, надежностью и дешевизной техподдержки^[1].

Рассмотрим существующие системы поддержки разработки под этим углом. Для иллюстрации представим картинку напоминающую «магический квадрат Gartnerа», но, предупреждаем, — она не претендует на точность и полноту, и нужна только для иллюстрации представляемых идей.

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

В левом верхнем квадранте живут монструозные платные системы, обычно интегрирующие системы вокруг IDE (Visual Studio или Eclipse), или с вебинтерфейсом. Да, интеграция вокруг Visual Studio очень удобна для разработчика, работающего только в технологическом стеке Microsoft, и если в фирме вся разработка такая — выбор может быть вполне оправдан.

Если же часть компании работает с стеком J2EE, часть с LAMP, часть с Microsoft, часть — серверная логика на Oracle (и т. п.) — то все плюсы сразу становятся минусами.

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

Так может рассмотреть открытые (бесплатные, и с открытым исходным кодом) интегрированные системы?

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

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

То есть, тут собрались очень мощные системы — с тысячами разработчиков и десятками тысяч пользователей. Например,

Bugzilla: учет задач, ошибок, проблем, ведение журналов работ, учет оргфокуса.
Testopia: интегрированная с Bugzilla система управления тестами.
MediaWiki: документирование, постановки задач и требований, ведение базы знаний компании, и даже блогов сотрудников.
Subversion: вершина эволюции в централизованных системах контроля версий.

Также там находятся свободные системы, для которых нет свободных систем аналогов (и даже аналогов в мире платного софта):

ViewVC: веб-интерфейс к Subversion, важный «клей» между Subversion и остальными вебсистемами.
SVNSearch: полнотекстовый поиск по всей истории Subversion-репозитариев.
FeedOnFeeds: карманный «Google Reader», то есть корпоративный RSS-агрегатор с веб-интерфейсом.

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

Ещё пример: MediaWiki — отличная, можно сказать, ведущая вики-система, но из-за основной направленности — открытые энциклопедии, в ней не развита система прав. И более того — несмотря на то, что многие пользователи запрашивают хорошую поддержку прав в MediaWiki, её архитектура была и остаётся открытой. И более того — хорошо, если так и останется. Причина в огромном числе расширений, уже написанных, и ничего не подозревающих о системе прав, и открытом доступе к БД из любого расширения. Почему же это хорошо? Хорошо это потому, что если бы этого не было, не было бы и этого огромного числа расширений («глобально-надёжные» системы вроде неторопливой «энтерпрайз-лэвел» Java — не конёк огромных открытых сообществ разработчиков), а следовательно, и система не была бы так популярна, а следовательно, и развитие её было бы тоже замедлено.

И вообще, единая система прав и авторизации, — это самое важное, когда требуется «приручать диких животных» — то есть укрощать и интегрировать дикие вебсистемы.

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

Да, объем таких доработок будет относительно ничтожным, по сравнению с общим объемом системы (например, в MediaWiki больше 2 миллионов строчек кода и доработка/расширение в 100—200 строчек, будет меньше сотой доли процента).

И о таких подходах часто рассказывают на конференциях (как докладчики, так и участники) и в интернете.

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

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

Поэтому («Talk is cheap, show me the code» © Линус Торвальдс) мы идем на большее, — мы публикуем в open-source полностью все используемые нами системы, с доработками и расширениями. Кстати, еще одна проблема использования open-source — пользоваться им любят многие, но при этом не любят делиться своими доработками^[2].

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

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

↑ См. отчет Forrester: «ПО с открытым исходным кодом характеризуется лучшим качеством (76%), более высокой надёжностью (71%) и меньшими расходами на поддержку (71%)»
↑ См. «Open source's ardent admirers take but don't give» или перевод «Поклонники открытого ПО не склонны делиться. Логика автостопщиков»

Репликация: База Знаний «Заказных Информ Систем» → «Золотая середина: открытые системы поддержки разработки»

T

2010-08-27T16:32:51Z

VitaliyFilippov:

Ошибки (TemplatedPageList):

Неправильная опция )
Не задано ни одного ограничения. Полный список страниц не показывается.

РИТ-2010: Отчёт Виталия Филиппова

2010-08-19T11:46:14Z

BenderBot: 1 версия

Сайт конференции: http://www.ritconf.ru/
Даты проведения: 12-14 апреля 2010
Место проведения: Infospace (ИнфоПространство)

Организация нормальная. Затупов не было. Только Джонатан Вортингтон, разработчик Perl 6 / Rakudo, который очень любит beer/vodka и так далее, то ли не приехал, то ли приехал, но очень увлёкся beer/vodka и так далее, в первый день вместо него выступал Шитов. С едой всё в порядке, обед раздёлен на два — по часу с 45-минутным интервалом между ними, во время каждого «обеда» прекращает работу только один зал, а в остальных продолжаются доклады. Кофе-брейк вечером, очень мало плюшек, их сожрали в момент. В последний день было пиво и шашлык ~~из кролика~~. Кстати, о кролике: там был один товарищ, который умудрился купить билет на РИТ по тестовой цене в 50 рублей, которую после выкладки на боевой сервер не успели поменять. За скорость тестирования ему вручили приз — живого кролика, правда, карликового (то есть малопригодного для еды).

Была видеозапись и онлайн-трансляция (6 камер в каждом зале). Есть надежда, что видео с конференции не будет столь же бездарно пролюблено, как это было с Highload’ом.

«У меня сразу плохая новость — обед идёт сейчас и кончится где-то посередине доклада, так что … решайте …»

«Стас, ты сейчас либо оставишь людей без кофе-брейка, либо следующего докладчика — без аудитории»

Mindmaps: история и идеология

2010-08-19T00:32:59Z

StasFomin:

Видеозапись одного из регулярных внутренних семинаров.

Интеграция Open Source-систем для управления разработкой ПО (SECR-2007)

2010-08-19T00:24:51Z

StasFomin:

Выступление Стаса Фомина на конференции SECR-2007.

В некотором смысле сейчас устарело, вместо него рекомендуем посмотреть:

Но может представлять исторический интерес.

Введение в Subversion (Лекция 2009-03-31)

2010-08-19T00:07:22Z

StasFomin:

Лекция с курса «Разработчик СУБД», где мы готовили разработчиков информационных систем, владеющих всем инструментарием грамотного девелопера — системы контроля версий, управления конфигурациями и задачами, вики-системы и т.п.

Эта видеолекция «Введение в Subversion» — только введение, после были и практические занятия, и совместная командная работа над реальными проектами.

Есть и презентация (можно скачать и ее):

Да, в нашей компании основной системой контроля версий является именно Subversion, хотя есть несколько legacy проектов, до сих пор хранимых под CVS (мы не переносим их под SVN, т.к. все это имеет хитрую интеграцию с системами сборки и «проноса» версий). Местами у нас применяются и распределенные системы контроля (Mercurial и Bazaar), но в основном только для локальных операций конфигурационного управления, либо экспериментальных проектов. В целом, мы согласны с одним из идеологов Subversion, и мы рекомендуем прочитать серию его статей о Subversion в нашем переводе.

Репликация: База Знаний «Заказных Информ Систем» → «Введение в Subversion (Лекция 2009-03-31)»

РИТ:Высокие нагрузки-2008 (Отчет Стаса Фомина)

2010-08-18T18:48:24Z

StasFomin:

Замечания и предложения направлять автору.

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

Сразу замечу, хотя явно вроде не указано (в списке спонсоров-соорганизаторов десятки значков участников, даже «udaff.com»), что эту конференцию (highload.info, не путать с highload.ru) было бы правильней именовать «Яндекс:Нагрузки», ибо практически «контрольный пакет» всех докладов был от «Я», также было немало Я-участников в ~~узнаваемой униформе~~ креативных футболках. Похоже Яндекс тут был ключевым организатором, и ничего плохого в этом факте нет. Может стоило тогда так и назвать конференцию и провести ее на самой территории Яндекса, с экскурсиями по машинному залу и т. п. Когда-то (1999) я был в серверной Яндекса, но сейчас, думаю, там все сильно круче.

РИТ:Высокие нагрузки 2008 (Отчет Алексеева Алексея)

2010-08-18T16:37:49Z

BenderBot: 1 версия

Замечания и предложения высказывайте автору.

Отчет о посещении «РИТ: Высокие нагрузки 2008».

Макс: Application Developer Days 2010 - тезисы

2010-08-13T19:25:36Z

MaksTsepkov:

Автор: Максим Цепков, главный архитектор компании CUSTIS (Заказные ИнформСистемы).

Название доклада: Учетная машина — универсальная архитектура учетно-аналитических систем.

Запись доклада: Учетная машина (Максим Цепков на ADD-2010)

Хостинг для публикации наших проектов в open-source

2010-08-12T14:06:38Z

StasFomin:

Мы собираемся опубликовать большое количество наших внутренних доработок и расширений в open-source, и в связи с этим, нам интересно мнение наших потенциальных потребителей и контрибьютеров — какой хостинг кажется вам наиболее подходящим?

Голосуйте, каждый может выбрать три наиболее интересных варианта, вернее так — у вас есть три голоса, и вы можете распределить их среди представленных систем — можно три раза проголосовать за один вариант, можно по разу за три разных, можно … ну вы поняли.

Какой хостинг кажется вам наиболее подходящим?

Вы можете использовать 3 голоса.

Хостить на нашей площадке, с инфраструктурой Bugzilla, MediaWiki, Subversion, SVNSearch, ViewVC
SourceForge
github
Launchpad
Freepository
Google Code
Bitbucket
CodePlex
assembla
GNU Savannah
Tigris.org
Все равно

См. также сравнение свободных хостингов.

Why I prefer no tabs in source code (Так говорил Виталий)

2010-08-11T14:47:58Z

BenderBot: 1 версия

Документ Why I prefer no tabs in source code начинается с очень разумной строчки:

Многие программисты смешивают в исходниках пробелы с табами — символами табуляции с ASCII-кодом 09, вместо того, чтобы использовать несколько (обычно 8) пробелов вместо таба.

Но дальше, вместо того, чтобы эту мысль развить, автор зачем-то переходит к другим, не очень разумным аргументам. Поэтому и существует «контр-документ» http://derkarl.org/why_to_tabs.html, который с точки зрения чёткости аргументации мне нравится больше, несмотря на то, что сам я в своём коде всегда использую пробелы.

Менее переносимо. Вопрос — как понимать «переносимость». Противник табов рассматривает «личную» переносимость — то есть, он сам взял и перенесся за другой компьютер или другой редактор, настройки табов там другие, а код всё равно выглядит так, как должен. Защитник табов же наоборот, рассматривает «гуманистическую» переносимость — если код перенёсся к другому человеку, у которого маленький монитор — или большой, 24", но повёрнутый вертикально :-) — или же у которого личные предпочтения в 8 пробелов — этому человеку не придётся прикладывать дополнительных усилий для переформатирования.
Сложно смотреть diff’ы — вообще полный бред. Первый символ в unified diff’е это " ", «+» или «-» вне зависимости от того, табы там или пробелы. Однако с аргументами защитника табов я здесь тоже не согласен — понятно, что при изменении стиля отступов меняются почти все строки файла. Понятно, что стилей отступов пробелами много, а стиль отступов табами один, и внутри стиля изменения целого файла не будет.
Становится сложно двигать блоки кода влево-вправо, например на 2 колонки — а нахрена блок кода двигать на 2 колонки?!! (по-видимому, не равные полному уровню отступа) Блоки хорошего кода должны быть выровнены на целое (а не дробное) число уровней отступа! Если же речь о выравнивании комментариев и прочей мутоты вроде многострочных прототипов и вызовов функций — это задача, отличная от выравнивания блоков кода, и нефиг использовать табы и для выравнивания блоков кода, и для выравнивания комментариев. Короче говоря, снова побеждает защитник табов… Правда, привнося в жизнь своих соратников некоторый геморрой в виде необходимости постоянно следить за тем, где ставить табы, а где ставить пробелы.
…какой-то код был написан на emacs с табами по восемь пробелов, но со стилем отступов «Kernighan & Ritchie», где отступы в 5 пробелов… — это не проблема табов, это проблема людей, смешивающих в отступах блоков кода табы с пробелами.

Смешивание пробелов с табами — это как раз то самое ужасное, что может быть в форматировании кода! Например, в UNIX’е многие (похоже, стандартно) считают, что размер таба — 8 символов, но отступ при этом — 4 символа. Получается, что 1 уровень — это 4 символа, 2 уровень — 1 таб, 3 уровень — 1 таб и 4 символа, и т. п. А потом прихожу я со своим нормальным размером таба в 4 символа и несмотря на то, что с авторами софтины, которую я правлю, мы сходимся во мнении насчёт размера отступа, его код выглядит у меня совсем не так, как планировалось — нечётные и чётные уровни будут попарно равны, потому что 1 таб = 4 символа.

Кстати, в защиту табов есть ещё один аргумент — когда код выравнивается табами, нигде в середине файла не может случайно попасться строка, выровненная «нецелым» отступом в, например, 7 пробелов. Пример: строка-конец многострочного массива (PHP). То есть на строке скобка и точка с запятой «);». В том же файле перед закрывающимися скобками — пробелы. Пришёл человек и решил автоматически переформатировать код — заменить « )» на «)», то есть, убрать пробелы перед закрывающимися скобками. Итог — строка со скобкой выровнена на (n*4-1) символ.

А вышеописанные плюсы пробелов вовсе не в том, что выравнивание пробелами корректнее. Плюс пробелов в том, что с ними тупо проще:

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

Why I prefer no tabs in source code

2010-08-10T17:32:42Z

BenderBot: 1 версия

Adam Spiers «Почему в коде я предпочел бы обойтись без табов»

Перевод статьи Why I prefer no tabs in source code

Я заметил, что несколько человек зашло на мою статью с статьи Why I love having tabs in source code, где автор пытается оппонировать моим аргументам против использования табов. (Замечу также, что автор весьма невежливо не поставил меня в известность о своей заметке, и, тем самым, не дал мне удобной возможности ответить). Он поднял интересные вопросы, правда проигнорировал некоторые мои. Хотя возможно он просто их не понял, тогда это моя вина, что я сформулировал их более ясно. Если выдастся время, я попробую это исправить и ответить на его заметку с более конкретными, проясняющими мою позицию, примерами.

Итак, вернемся к моей статье.

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

«Как правило» — это потому, что в любом правиле есть исключения, которые подтверждают все правила без исключения. Ниженаписанное относится в основном к свободному софту, потому что из-за «базарной»^[1] модели разработки высока публичность кода. Однако если вам не повезло, и вы работаете в компании не оставляющей никому выбора ни для правил отступов, ни текстового редактора, то, что поделать — эта статья вам все равно не пригодится.

Итак, это:

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

Становится очень сложно читать diff-результаты, как контекстные, так и в формате unified diff, так как там первый столбец означает тип изменения строчки. Для многих разработчиков сейчас это очень важно. И даже если вы разрабатываете ваш код в одиночку, насколько вы уверены, что никому и никогда не взглянет на ваш код, не будет его править и уж совсем никогда не пошлет вам патчи?

Вообще у diff есть пара решений для этого — опции --expand-tabs и --initial-tab, но ни оба из них недостаточны.

Становится сложно двигать блоки кода влево-вправо. Например, вы пытаетесь сдвинуть блок только на две колонки вправо — и это не действует на строчки начинающиеся с табов.

Конечно, можно сказать все это не нужно, если у вас вменяемый редактор, делающий автоматический отступ, но автоматика не всегда срабатывает верно, особенно для Perl-а, когда даже GNU emacs не в силах разобраться с синтаксисом.

И опять таки, вы уверены, что никто кроме вас не захочет переформатировать ваш код? Точно уверены? Сто пудов? Уверены что вы никогда не будете копипейстить фрагменты кода в почте? Ну, представьте, что будет с этим кодом, кто-то ответить на такое письмо.

Аргумент «табы хороши, потому, что каждый может выбрать удобную для себя ширину отступов» не работает, потому что:

Табы используются не только в начале строк. Может многострочный комментарий, с левым выравниванием текста, но размещенный справа от кода, в общем, вглянем на реальный пример из /usr/include/gmp.h, найденный на FreeBSD-системе:

typedef struct
{
  int _mp_alloc;                /* Number of *limbs* allocated and pointed
                                   to by the D field.  */
  int _mp_size;                 /* abs(SIZE) is the number of limbs
                                   the last field points to.  If SIZE
                                   is negative this is a negative
                                   number.  */
  mp_limb_t *_mp_d;             /* Pointer to the limbs.  */
} __mpz_struct;

И теперь представим бедолагу сидящего за терминалом 80x25, и решившего просмотреть форматированный табами код, но, не с жирными 8 пробелами на таб, ведь было бы ужасно читать из-за переносов строк или выходов за границы экрана, а задав 2 или 3 пробела на таб. Итак, он печатает

 less -x2 foo.c

и бах — внезапно прямоугольные блоки комментария справа перестают быть выровненными по левому краю — что за фигня!

Проблемы могут быть даже если табы только в началах строк. Допустим, какой-то код был написан на emacs с табами по восемь пробелов, но со стилем отступов «Kernighan & Ritchie», где отступы в 5 пробелов. Если emacs настроен на использование табов, строчки с одним отступом будут отбиты пятью пробелами, строчки с двумя отступами будут отбиты табом и двумя пробелами (8 + 2 == 10).

Если кто-то еще захочет просмотреть этот код в редакторе/листальщике с табами по 4 пробела, то в строчках с единичной глубиной будет отступ на 5 колонок, следующий уровень — 6 колонок, третий уровень — 11 колонок… Упс!

Этот же аргумент можно адресовать и к пробелам. Хотите взглянуть на исходники, чтобы двухколоночные отступы показывались как четырехколоночные? Без проблем:

$ perl -pe 's/^((  )+)/$1$1/' foo.c | less

Хотите переформатировать 8-колоночные отступы в трехколоночные? Легко:

$ perl -pi -e 's/^( +)\1{7}/$1 x 3/e' foo.c

Очевидно, можно написать простой Perl-скрипт или макрос для редактора, чтобы сделать эти операции еще более простыми.

А вы что думаете?

Я всегда интересуюсь чужой точкой зрения на этот вопрос. Может я что-то упустил? Или даже вы попробуете доказать мне что, я ошибаюсь?!

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

Будь любезен, сделай всем одолжение! Напиши в свое ~/.emacs:

(setq-default indent-tabs-mode nil)

или в своей ~/.vimrc:

:set expandtab

Пишите, пожалуйста, мне, как это сделать в других текстовых редакторах.

↑ Метафора отсылает к известному эссе «Собор и Базар» о конкурирующих парадигмах разработки корпоративного и свободного программного обеспечения.

Why I love having tabs in source code

2010-08-10T17:21:49Z

BenderBot: 1 версия

Перевод статьи http://derkarl.org/why_to_tabs.html

Многие делают отступы пробелами. Но в целом, это плохая идея. Если бы табы использовали для отступов, а пробелы — для остального форматирования, проблемы бы не было. По крайней мере современные редакторы, такие как VIM и KWrite, нормально обращаются с табами.

Мои контраргументы к утверждениям статьи «Why I prefer no tabs in source code», агитирующей за пробелы:

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

На самом деле это более переносимо. Я не знаю никого, кто делает отступы пробелами, восемь раз нажимая на пробел, просто они обычно настраивают их текстовый редактор, что таб это восемь пробелов. И неважно, насколько «глубоки» и «широки» ваши табы, читатель просто настроит глубину табов как ему удобно, без необходимости переформатировать файл, ведь переформатирование файла (даже с одним отступом) делает сравнение полностью невозможным, ибо изменяется все! Табы решают эту проблему, можно интерпретировать их как 4-пробельные или 8-пробельные отступы, без изменения файла.

Становится очень сложно читать diff-результаты, как контекстные, так и в формате unified diff, так как там первый столбец означает тип изменения строчки. Для многих разработчиков сейчас это очень важно. И даже если вы разрабатываете ваш код в одиночку, насколько вы уверены, что никому и никогда не взглянет на ваш код, не будет его править и уж совсем никогда не пошлет вам патчи?

Это совершенная неправда, на самом деле, как я выше уже утверждал, отступы с табуляциями упрощают чтение diff-ов.

Становится сложно двигать блоки кода влево-вправо. Например, вы пытаетесь сдвинуть блок на две колонки вправо — и это не действует на строчки начинающиеся с табов.
Конечно, можно сказать все это не потребуется для вменяемые редакторов, которые делают автоматические отступы, но автоматика не всегда может сработать правильно, особенно для Perl-а, когда даже GNU emacs не в силах разобраться с синтаксисом.
И опять таки, вы уверены, что никто кроме вас не захочет переформатировать ваш код?

Автоматическое переформатирование ваших файлов с использованием sed или perl на самом деле гораздо легче, если используются табы, так как каждый уровень задается в точности одним символом, и не надо подсчитывать пробелы, пытаясь определить ширину таба — 8, 4 или сколько там еще пробелов. А редакторы, которые не справляются с табами, — это вовсе не редакторы, а недоразумение (вспоминается emacs).

Аргумент «табы хороши, потому, что каждый может выбрать удобную для себя ширину отступов» не работает, потому что:

Табы используются не только в начале строк. Может многострочный комментарий, с левым выравниванием текста, но размещенный справа от кода, в общем, вглянем на реальный пример из /usr/include/gmp.h, найденный на FreeBSD-системе:
typedef struct
{
  int _mp_alloc;                /* Number of *limbs* allocated and pointed
                                   to by the D field.  */
  int _mp_size;                 /* abs(SIZE) is the number of limbs
                                   the last field points to.  If SIZE
                                   is negative this is a negative
                                   number.  */
  mp_limb_t *_mp_d;             /* Pointer to the limbs.  */
} __mpz_struct;
И теперь представим бедолагу сидящего за терминалом 80x25, и решившего просмотреть форматированный табами код не из расчета 8 пробелов на таб, ведь это было бы ужасно читать из-за переносов строк или выходу за границы экрана, а задав 2 или 3 пробела на таб. Итак, он печатает less -x2 foo.c и бах — внезапно прямоугольные блоки комментарие справа перестают быть выровненными по левому краю — что за фигня!

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

Проблемы могут быть даже если табы только в началах строк. Допустим, какой-то код был написан на emacs с табами по восемь пробелов, но со стилем отступов «Kernighan & Ritchie», где отступы в 5 пробелов. Если emacs настроен на использование табов, строчки с одним отступом будут отбиты пятью пробелами, строчки с двумя отступами будут отбиты табом и двумя пробелами (8 + 2 == 10). Если кто-то еще захочет просмотреть этот код в редакторе/листальщике с табами по 4 пробела, то в строчках с единичной глубиной будет отступ на 5 колонок, следующий уровень — 6 колонок, третий уровень — 11 колонок… Упс!

Во-первых, K&R-стиль давно устарел. Ничего страшного, если вы смените K&R-стиль на табы, где табы ровно X пробелов, и где каждый столбец будет на уровне кратном X.

На самом деле, преимущество табов можно увидеть на примере CVS-репозитория kde.

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

И только малая часть модулей (aRts, Noatun) на 100% последовательна — та, где код форматируется табами.

Лучше делать форматировать так (обозначим табы подчеркиваниями, а пробелы — точками):

_____if.(true)....//This should be replaced
_____{............//with a proper boolean
__________func();
_____}

На любом уровне, все будет выравнено:

SomeClass::SomeClass()
_____.:.InheritingClass(false, false
_____...................5, 10, true,
_____...................bleh, blah)
{
// ....
};

// vim: ts=4 noet

Репликация: База Знаний «Заказных Информ Систем» → «Why I love having tabs in source code»

Test/Keepalive

2010-08-04T12:34:07Z

TestBot: Automatic test: 2012-10-25 14:19:44

Страница для автоматических тестов MediaWiki.

Automatic test: 2012-10-25 14:19:44.

Python x64 для Windows 7

2010-08-03T18:04:28Z

BenderBot: 1 версия

Под 64 битной Windows 7 есть желание и Python поставить 64 битный, чтобы щедро кормить его памятью, ну и вообще.

Однако те, кто расслабился и привык инсталлировать все расширения через easy_install ждет разочарование — нет готовых бинарников, увы (на лето 2010).

Что делать? Ну, совсем быстрое решение — воспользоваться благотворительностью добрых людей и поставить таки собранные бинарники под 64 бита, и опубликованные тут http://www.lfd.uci.edu/~gohlke/pythonlibs/

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

Но все же, большинство расширений скомпилируются и встанут, только нужно им правильно настроить C-компилятор.

Правильный компилятор — родной для питона 2.6 и 2.7 с python.org это Microsoft Visual C++ 2008.

Если вы счастливчик, и у вас он стоит и настроен, то скорее все будет ОК.

Но что делать тем, кто не собирается его покупать? Тут требуется пройти небольшой квест.

Установите Microsoft Visual C++ 2008 Express Edition (именно 2008, не 2010).
Пропишите путь C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC в переменную PATH.

Ни в коем случае не добавляйте этот путь в кавычках! Без кавычек!

Установите Microsoft Windows SDK for Windows 7 and .NET Framework 4 в пути по умолчанию. Ничего не меняйте!
Создайте файл

C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\bin\amd64\vcvarsamd64.bat

с содержимым

call "C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\SetEnv.cmd" /x64 /Release

Поправьте файл C:\Python27\Lib\distutils\msvc9compiler.py

в районе 648 строчки, после строк

            temp_manifest = os.path.join(
                    build_temp,
                    os.path.basename(output_filename) + ".manifest")
            ld_args.append('/MANIFESTFILE:' + temp_manifest)

добавьте строчку

            ld_args.append('/MANIFEST')

Теоретически, теперь должно компилироваться. Возможные проблемы (с чем столкнулся я) будут ниже.

Сравнение DVCS - несколько задач

2010-08-02T15:02:34Z

BenderBot: 1 версия

Данная статья является очередным сравнением популярных DVCS — Mercurial, Git и Bazaar, с точки зрения нескольких нетривиальных задач.

Хотите лаконичный ответ в стиле «ИМХО» на вопрос — кого выбрать из трёх? Ну пожалуйста. Выбирайте Mercurial. А не Git (безумный конгломерат) и не Bazaar (пионерское поделие, унаследованное от Arch’а).

Интервью Стаса Фомина для ADD-2010

2010-08-02T08:03:04Z

BenderBot: 1 версия

Чтобы прояснить, какие люди замешаны в организации конференции Application Developer Days 2010, главный организатор конференции, Андрей Майоров взял интервью у председателя Программного Комитета Стаса Фомина.

Разработка систем на базе адаптивных моделей

2010-07-16T16:00:18Z

BenderBot: 1 версия

Большие проекты в Agile (AgileDays-Екатеринбург-2010)

2010-07-04T16:13:17Z

StasFomin:

Докладчик: Михаил Заборов

Креативное программирование 2.0

2010-06-16T12:45:18Z

VitaliyFilippov: Массовая правка: замена Категория:Рецензии на Категория:Рецензии на книги, замена Category:Рецензии на Category:Рецензии на книги

Автор(ы): Гласс Р.
Страница книги на сайте издательства: http://www.symbol.ru/alphabet/666333.html

Продуктивный программист. Как сделать сложное простым, а невозможное – возможным

2010-06-16T09:56:37Z

VitalyKozlovtsev:

Автор(ы): Нил Форд
Страница книги на сайте издательства: http://www.symbol.ru/alphabet/645323.html

FreeMind

2010-06-16T09:50:56Z

BenderBot: 1 версия

FreeMind — редактор «карт памяти». Инструмент для планирования и мозгового штурма, а также для иллюстрации текста красивыми «картами».