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

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

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

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

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

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

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

По просьбам трудящихся — перевод статьи Пола Грехема (Paul Graham) ‘Holding a Programm in One's Head’.

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

Навеяло. Готовил материал на cornflake.ru, и вдруг сделал статью собственного сочинения.

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

Когда перед нашей фрилансерской группой встала задача документирования проекта, были сформулированы следущие требования:

• Как известно, программисты, обычно, не очень любят писать документацию… поэтому чем проще и комфортнее будет её писать, тем больше вероятность, что её таки будут писать.
  
  • Поскольку мы работаем из дома, то должна быть возможность писать документацию локально, на своей машине.
  • Чтобы это было делать комфортно, нужна возможность использовать для этого любимый текстовый редактор, никаких форм на вебсайтах а-ля вики или систем заточенных под конкретный редактор/IDE.
  • С доступом в инет у всех по-разному, и чтобы исключить ситуацию, когда документация небыла написана исключительно потому, что когда появилось настроение её писать по закону подлости отвалился инет — для написания документации не должен требоваться инет.
• Документация должна быть доступна всем, кто работает над проектом. Это включает как возможность читать её через вебсайт так и работать с ней как с обычными локальными файлами.
• Желательно, чтобы документация поддерживала какой-нить язык разметки и гиперссылки, чтобы её было удобно читать.
• Возможность редактировать документацию из браузера (а-ля вики) желательна, но не очень важна (разработчики будут работать с файлами, так что эта фича может пригодиться в основном клиенту, который врядли будет напрямую править документацию).

Введение.
Вот уже 5 лет я занимаюсь веб — разработками. За это время приходилось и на коленке делать сайты за несколько сотен долларов и участвовать в довольно крупных проектах. За последний год меня не оставляет ощущение deja vu. Где-то я уже видел: нервных заказчиков, взбешенных менеджеров, заваленных работой разработчиков и сорванные сроки. При этом для меня ничего не изменилось. Были все те же нечеткие, постоянно изменяющиеся требования, прессинг, и ни одного проекта, сданного в срок…
И это, не смотря на то, что “грабли” были всегда одни и те же.

Имеем корпоративный сайт. На таком сайте размещена информация о компании, услугах, которые компания предлагает, а также, возможно, каталог продукции. Как сделать так, чтобы пользователь мог легко общаться (задавать вопросы) компании?

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

Плюсы более-менее очевидны:

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

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

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

На Хабре общается немалое количество менеджеров интернет-проектов и не меньше разработчиков: дизайнеров, программистов. Из своего опыта знаю, что часто бывают моменты непонимания одних другими. Чтобы как-то помочь и тем и другим достичь взаимопонимания, предлагаю резюме статьи Роба Уаллинга (Rob Walling):

Недавно в офисе Хабра я хотел прочитать своим коллегам небольшой доклад об объектной ориентации и наследовании классов в JavaScript.

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

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

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

Весь текст подеён на 5 разделов:

1. ООП в Java Script (1/5): Объекты
2. ООП в Java Script (2/5): Классы
3. ООП в Java Script (3/5): Свойства и методы класса
4. ООП в Java Script (4/5): Наследование классов
5. ООП в Java Script (5/5): Полезные ссылки

Это выдержка заметки в блог IM (link) на тему оригинального механизма регистрации и авторизации на сайте + еще пару мыслей об интеграции веб с нашей повседневной жизнью.

Предыстория

Существуют разные системы и способы организации дел, напомниания о них.
Я имел когда-то два icq uin'a (рабочий\домашний) для этих целей. Т.е. вместо писем я посылал im-сообщения самому себе, чтобы по приходу (поймите правильно) не забыть сделать важные вещи. До недавнего момента, к сожалению, использовал две jabber-аккаунта для тех же целей (тут даже идея приоритетов помочь не может).

Но всё изменилось

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

Когда-нибудь каждый JavaScript-программист осознаёт, что JS — объектно-ориентированный язык. И здесь его подстерегают некоторые опасности, происходящие от непонимания того факта, что JS — язык не классов (как Паскаль или Цэ-два-креста), а прототипов.
Так, уже многое написано о проблеме наследования (котого в JS нет). Я же постараюсь рассказать о менее освещённом, но едва ли не более важном подводном камне: грамотной реализации методов.
Программисты пытаются объявлять классы в привычной для них форме, из-за чего возникают утечки памяти и прочие неприятные вещи. На самом деле нужно всего лишь научиться использовать прототипы.
Эта статья предназначена прежде всего для начинающих JS-программистов.

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

Nokia Mobile Web Server — вебсервер для телефонов платформы S60, основанный на порте популярного веб-сервера Apache.
Apache идет вместе с предустановленными модами: mod_alias, mod_auth, mod_autoindex, mod_dav, mod_dav_fs, mod_dir, mod_log_config, mod_mime, mod_rewrite, mod_setenvif и (!) mod_python.

Поговорим о всем известном свойстве float, не менее известном position и их соседе — display.

Как известно, в css есть понятие «схема позиционирования». Этих схем позиционирования есть три вида — нормальный поток, поплавки и абсолютное позиционирование.

Теперь необходимо ввести некоторые термины, прежде чем написать то, что я хочу донести.