Пол дня провёл в поисках простого и приемливого способа определить версию Flash плеера и вот нашёл, как мне кажется, достойное решение:
http://www.cdp.tti.sfedu.ru/flash/flashversion.html
Тырим скрипт (лицензия MIT) и, как видно в коде страницы,
var version = deconcept.SWFObjectUtil.getPlayerVersion();
даёт нам маленький массив, в котором version.major – версия установленого плеера. Если не установлен, то в результате ноль.
Пользуйтесь!

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

Дальше…

Привет всем

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

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

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

Дальше…

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

Дальше…

Видео семинара Дениса Петелина «Самоуправляемая команда – как ее построить?», организованный Гильдией менеджеров программных проектов 2 февраля 2010

В некоторых книгах описывается, как умные люди собираются вместе, продуктивно дискутируют, продумывают архитектуру, устанавливают процесс, сознательно ему следуют – и все это вообще без принуждения. Когда вдохновленный очередной демаркой менеджер пытается поступить таким образом – он видит, что никакой самоорганизации не происходит: вялая возня, бесконечная ругань, отсутствие прогресса – до тех пор, пока он не возьмет все в свои руки и не начнет жестко командовать. Почему так происходит? Вот на этот вопрос и постарался ответить семинар!

Поведать я хочу об ужасном. Об ужасном заболевании многих cms – тотальном отсутствии документации. С этой проблемой я столкнулся не далее, как на прошлой неделе – именно тогда я получил задание от руководства написать модуль для системы управления проектами DotProject (текущая версия – 2.1.1). Итак, скальпель, свет! Приступим к вскрытию тела.
Дальше…

Вот дюжина причин почему по моему мнению стоит выбрать Git:

1. Git работает существенно быстрее.
2. Git – распределённая система. А это значит, что коммиты кода можно делать постоянно, не боясь залить в репозитарий неверный код и испортить работу боевым товарищам.
3. Из первой причины вытекает вторая – каждый работает со своей копией репозитария локально в любых условиях.
4. Каждый разработчик фактически работает со своей веткой проекта. Это настолько нативно, что девелоперы привыкают использовать ветки – сразу появляется желание и, главное, возможность вносить любые экспериментальные изменения, разрабатывать новый этап – всё в отдельной ветке.
5. Ветки и распредёлнная структура позволяют реализовать произвольную иерархию работы с репозитарием. Например можно реализовать классическую схему работы с центральным репозитарием (аля SVN), а можно реализовать систему иерархий, когда все получают код из основного репозитария, а коммитят результат работ в репозитарий teamleader, который делает коммит в основной репозитарий самостоятельно.
6. Git устроен так, что его main (trunk выражаясь терминами SVN) содержит всегда последнюю стабильную версию. Все промежуточные результаты находятся в ветвях. Выкладывать проект на «боевой» сервер можно хоть по крону (cron) каждый день в 0-00
7. Клиенты для Git есть на сегодняшний день для всех популярных ОС.
8. Размер репозитария небольшой, в сравнении с конкурентами (svn, csv) он значительно меньше.
9. Staging Area – предпросмотр коммита и средство частичного коммита одновременно (см. документацию Git)
10. Перейти на Git не сложно (если вы используете SVN, то можете начать с git-svn bridge, чтобы не заставлть переходить на git сразу всех своих девелоперов). Начать с ним работать – просто (для начала работы достаточно просто сделать git init и git add . в директории – далее см. git help).

На сайте axiis опубликован интересный  модуль построения графика.  на примере статистики посещаемости сайта w3schools построен график популярности браузеров с 2002 по 2009 г.

картинка кликабельная, надеюсь ссылка будет жить долго

1. Software Configuration Management // Распределенный контроль версий

Приветствую. Как и обещал — продолжение цикла заметок об управлении конфигурацией ПО, в простонародье называемом Software Configuration Management. Весь цикл можно найти по ссылке на тэг CM. Из ещё неохваченного осталась буквально пара заметок.

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

более подробно на хабре

2. Командная работа в Git

Во всем множестве статей по git’у, которые я смог найти в сети, не хватает одного существенного момента — описания командной работы. То, что обычно описывают как командную работу, на самом деле является просто работой с удаленным репозиторием.

Ниже я хочу описать свой опыт командной работы над проектом с использованием git’а.

подробнее в ЖЖ у автора (m-иванова) или на хабре, кому как удобнее

3. Коллективная разработка с использованием git и Trac в проекте Midnight Commander

Действительно, в интернете сейчас можно найти достаточно много информации о настройке GIT и работе с ним, но недостаточно освещен вопрос коллективной разработки и «рабочего процесса» отдельно взятого проекта от начала и до конца.

Попробую восполнить этот пробел на примере открытого проекта Midnight Commander, не останавливаясь на вопросах установки необходимого ПО, так как этот момент неплохо описан в интернете, и вы сможете легко найти интересующую вас дополнительную информацию самостоятельно.

Используемые термины и определения

• тикет — отчёт об ошибках либо о пожеланиях, улучшениях. Иные названия — багрепорт и т.п.
• бранч — ветвь разработки, существующая в системе контроля версий (в git)
• апстрим — главная ветвь в системе контроля версий. Для git это обычно ветвь «master»
• стабильная ветвь — ветвь отпочковавшаяся от ветви «master» тэгированная и выпущенная в качестве релиза (в дальнейшем сопровождается отдельно)

более подробно на хабре

4. десяток полезных советов

ХХ полезных советов для пользователей Git среднего уровня. Часть 1

Вообще-то изначально я планировал перевести статью Энди Джеффриса (Andy Jeffries) 25 Tips for Intermediate Git Users, но в процессе я отбросил бестолковые, общеизвестные или самые простые советы вроде «настройте первым делом user.name и user.email», которые явно не подходят людям, уже более-менее плотно знакомым с Git.
Взамен я дополню статью моментами из личной практики («Своя практика»! Звучит здорово, будто я частный врач или адвокат! :-] )

http://habrahabr.ru/blogs/Git/75728/

ХХ полезных советов для пользователей Git среднего уровня. Часть 2

Это продолжение статьи ХХ полезных советов для пользователей Git среднего уровня

Про reset, незапланированно снова про альясы, про замечательный filter-branch, про мерджи и разрешение конфликтов с помощью rerere, про rebase (интерактивный и не очень) и, в завершение, про обслуживание своей гитницы.

http://habrahabr.ru/blogs/Git/76084/

5. Внешние зависимости в гите: submodule или subtree?

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

У моего проекта несколько зависимостей. Бóльшая часть зависимостей живет в гитовых репозиториях. Сам проект тоже живёт в гите.

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

http://habrahabr.ru/blogs/Git/75964/

6. Пример использования хуков (hooks) в git

Для того чтобы познакомиться с механизмом хуков в git, достаточно просто начать их использовать и посмотреть как оно работает, и как оно устроено внутри.
Хуки в git это некие скрипты, срабатывающие на определенные события, по сути своей являются их обработчиками. Расположены они в каталоге .git/hooks.

Для примера попробуем сделать простенький обработчик. Его задача поместить в редактируемое описание к коммиту нужную нам информацию.

http://habrahabr.ru/blogs/Git/75063/

7. Особенности настройки git под windows

Проблемы с русскими символами в git

Когда вы начнете работать с версией git под windows в командной строке, вы столкнётесь со следующей проблемой — все сообщения git, в которых фигурируют русские символы будут нечитаемы. Имена файлов, на русском языке, будут выглядеть так — «\362\345\361\362″, а тексты коммитов примерно так — <C8><ED><E8><F6><E8><E0><EB><E8><E7><E0><F6><E8><FF> <EF><F0><EE><E5><EA><F2><E0>. Т.е. исходная строка преобразуется в utf8 в соответствии с кодировкой latin1.

http://habrahabr.ru/blogs/Git/74839/