В процессе поиска иконки для заметки наткнулся именно на эту. Мне она показалась подходящей т.к.хорошо отображает суть: процессы ветвления и слияния.
Но если вы настаиваете, то я конечно же сменю :)
Почему в качестве иллюстрации к вашей статье выбрана иконка проекта 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.
Последние комментарии