Совсем недавно, co-founder проекта GitHub по имени Tom Preston-Werner (аka mojombo), на радостях от переезда с Engineyard на Rackspace написал очень подробную статью о внутренних составляющих их детища. Краткая выдержка как всегда под катом.
Давненько хотел посмотреть в сторону распределенных систем контроля версий (DVCS). Не то, чтобы меня совсем не устраивал традиционный SVN, просто хотелось увидеть причины, по которым многие разработчики отказались от того же SVN/CVS. Чтобы не жалеть о выборе решил немного понаблюдать, что же происходит на поле этих самых DVCS. Заметных игроков здесь несколько: это git, bazaar и mercurial. Но презентация Линус Торвальдса в google расставила все точки над i. Под катом припасенные мной ссылки на разного рода полезную информацию.
В первую очередь хотелось бы поблагодарить организаторов. Ведь это мероприятие получилось только за счёт энтузиазма организатора и его жены и проходило в самом подходящем месте -- аудитория мех. мата университета Каразина.
На днях вышло pecl расширение для PHP под названием libevent. Как видно из названия, оно позволяет использовать event-driven подход в приложениях, написанных на PHP, используя libevent.
Различные библиотеки, использующиеся в PHP для доступа к хранилищам данных, предоставляют возможность создания постоянных соединений (pconnect, или persistent connect). В их число входят mysql, postgresql, memcache и другие. Использование этих функций сулит нам экономию на время установления соединения. Но какой ценой ?
На днях обновился Meld -- инструмент для визуального слияния и просмотра изменений в файлах для всяких *nix-ов. Дороос он уже до версии 1.3.1 . Так как я не представляю себе ежедневной работы без этой софтины, новость очень порадовала. Без промедления побежал обновляться. Из нового стоить отметить такие вещи:
В процессе поиска иконки для заметки наткнулся именно на эту. Мне она показалась подходящей т.к.хорошо отображает суть: процессы ветвления и слияния.
Но если вы настаиваете, то я конечно же сменю :)
Почему в качестве иллюстрации к вашей статье выбрана иконка проекта Bazaar VCS (http://bazaar-vcs.org)? Это для чего? Из вашей статьи следует, что bzr вы не пользовались и переезжаете с SVN на Git. Каким тут боком bzr?
Пожалуйста, уберите. Иконки svn или git можно взять на соответствующих сайтах.
Я наверное неправильно выразился. Перенес именно с помощью git-svn. Других простых путей я не нашел.
А комментарий был на тему того, что _постоянно_ пользоваться git-svn не хотелось, ибо лень :)
В итоге, по факту, пока приходится вручную sync-ать в свн с помощью старого доброго meld.
> Якби ще цей wordpress...
Это не вордпресс, а собственная разработка. Этот блог отчасти для его обкатки.
А комментарии на почту скоро появятся. Совсем недавно мой коллега написал плагинчик delayed job, который сейчас тестируется. Он как раз таки и будет рассылать почту подписчикам.
А як же тоді перенести історію розробки з svn у git? Є ще якийсь шлях крім git-svn?
Якби ще цей wordpress присилав повідомлення про нові коментарі, ціни б йому не було…
Но это была бы полумера. Да и я несколько ленив, поэтому не особо хотелось разбираться с git-svn. А разбираться, уверен, пришлось бы, т.к. ну не может всё проходить гладко -- рано или поздно возникнет неведомая х%ня, которая заставит прочесть man-ы от корки до корки.
Щоб перехід був не дуже болісний, можна було б деякий час покористуватися git-svn. Ця цяцька дозволяє не тільки перенести історію svn у локальне сховище git, але й навпаки.
Слушал вопрос по экономической эффективности.
Ответ очень прост на самом деле:
если проект будет на малое количество времени и поддержки особой не планируется. То есть через полгода-год - забыли про его существование, то эффект минимален.
А вот если проект будет долгим(несколько лет с непостоянными доработками), то тут уже очень полезно. Уволят человека, которые сделал какую-то важную фичу, если тестов нет, то 100% с первого раза не получится что-то добавить правильно и 95% что тестеры пропустят какую-то мелочь, которая использует эту фичу не совсем стандартно.
Очень было весело, когда один большой проект(без юнит-тестов) релизился с увеличением major версии. Тестеры проходили по всем кнопочкам. Находилась в первый раз штука, которая не работает. Ее быстренько подпиливали. Тестеры опять нажимали все кнопки. Версию отсылали клиентам. У какого-то из крупных клиентов раз в два-три релиза возникала ошибка в расчетах или в сохранении. Потому неделю все ждали ответа от пользователей нет ли какой ошибки.
После моего ухода оттуда ввели зачатки по автоматизированному тестированию (клик на все кнопки) - одного тестера уволили. Начальник отдела проверяет правильность некоторых часто используемых вычислений запуском отчетов. (Фактически те же юнит-тесты). Баг-фиксы к релизам для всех уже не высылают. Тногда только какая-нибудь мелочь для клиентов, которые жалуются. Скорость разработки увеличилась.
Ну, во многих аспектах он ошибается. Главный его посыл -- запуск программы каждый раз при новом запросе, "программист теперь не привязан к постоянному перезапуску "приложения"". Есть системы из мира JavaEE, где приложение постоянно висит в памяти, и не запускается при каждом запросе. Как раз таки вызывается только нужная часть функционала.
ИМХО, AJAX придуман не столько для "процедурности", сколько для более быстрой доставки информации. Если нужно изменить только небольшой блок страницы, зачем перегружать ее снова. AJAX-иком аккуратно его изменяем.
Про кодировки -- на дворе 21 век. Unicode-у уже лет 15. Если разработчик не использует его, ну тогда придется заморачиваться с однобайтными кодировками. Как говорится, сам себе злобный буратино.
"Нет такого свойства, чтобы готовые binary данные вставить в элемент."
Очень давно существует.
img src="data:image/gif;base64,
и погнали.
Да и про JavaScript тоже местами гониво. JS приложения можно успешно запускать не только в браузере.
Например, nginx -- даже не обвязка, а полностью построенный на event-ах веб-сервер. А если поразмыслить, любую систему можно свести к event-ориентированной, где те или иные части срабатывают по наступлении определенного события.
>Если честно, не очень понятно, что же выделилось из проекта.
Ничего не выделялось. Был преобразован код. Похоже, что всё движется к чему-то вроде pecl extension.
> О динамическом количество воркеров видимо так и придется только мечтать
Это стоит в планах. Как только Майкл найдет программистов и финансы, эта фича будет реализована.
Rapid по сравнению с чем ? Порой, оптимизация базы данных для уменшения нагрузки на систему, в целом занимает большой промежуток времени и требует знаний по внутреннему устройству конкретной СУБД. А это уже совсем не "Rapid".
Если честно, не очень понятно, что же выделилось из проекта. Понятно, что Андрей по видимому пока этим заниматься не будет, Michael на launchpad замутил, что-то отдельное, только вот что-то не уловлю что...
Написано, теперь патчить ни чего не нужно. Получается это некий отдельный FastCGI менеджер который запускает скрипты? Как я понимаю ни каких отличий от версии когда нужно патчить нет? О динамическом количество воркеров видимо так и придется только мечтать...
Дануна! У них базы песец перегруженные, вот и денормализуют за счет программеров. Нам-то это зачем? Мы как раз SQL любим именно за его простоту и возможность RAPID DEVELOPMENT.
