Я тоже так и не смог понять, зачем может понадобиться такая связка redis+memcached. Проблемы у них не в скорости, а в чем-то еще, по словам докладчика. Вначале, для себя попытался найти следующее объяснение, что есть модуль в nginx который позволяет использовать memcached. Но погуглив нашел что есть решения позволяющие подружить nginx и redis. Но возможно эти решения не так хороши, как memcached + nginx.
А так, со стороны, кажется что ДЛЯ НИХ memcached лишний.
Согласен с некоторыми комментаторами что технологический аспект не самое главное. С современными камерами со сменной оптикой это уже не так важно, на мой взгляд. Конечно здесь я опираюсь на слова других фотографов, сам я таковым не являюсь. Именно поэтому, знание теории может существенно повысить качество снимков. Вот забавный ролик об Iphone vs Hasselblade. Понятно что это студия, но в статье часто звучало что смартфон не позволяет что-то сделать. Как-раз тут-то знания и нужны. Понятно что у "крутой" техники окно возможностей будет шире. Но даже обычный смартфон может вас удивить.
А мы договорились ставить с точность до 6 минут. Т.е. это 0.1. Я даже такую табличку написал для девушек филологов. :)
Ну и когда ты задачу берешь в работу то там фиксируется время. От него потом легко произвести вычисления.
Но ведь в windows все удобно. Даже домохозяйка разберется. Тыц — тыц мышкой и настроит любую роль для сервера.
Чтобы контроллер домена поднять вообще особо не надо напрягаться. А если что-то сломается, то все легко и самостоятельно
исправится.
:)))
Мы вот тут недавно вызывали себе администратора для установки Windows Server 2012. Он там немного завис. Говорил что немного поменялось все. Меня лично порадовал на сервере стартовый экран в стиле Метро.
:))
У нас в конторе пока «пачка разных ОСей». В первую очередь дизайнеры сидят под виндой. Остальных потихоньку двигаем в сторону линукса.
Я хотел добавить свои две копейки в эту дискуссию.
Один мой знакомый, побывав на одной из лекций Google Tech Talk, сделал вот какие для себя выдержки (далее я сохранил его грамматику):
Ребенок должен услышать 45М слов прежде чем начнет понимать их смысл.
The brain plasticity process is substantially reversable (большинство проблем, связанных с неправильным развитием, старением и даже неврологическими болезнями можно устранить или скорректировать).
В любом возрасте могут быть улучшены такие свойства мозга как достоверность восприятия, скорость операций, координация восприятия и т.д.
Способность мозга к специализации (приобретению новых навыков) снижается если он захламляется всякой хренью (шумом).
Почему с возрастом мозги обычно работают хуже: а) накапливается «шум», б) стареющего тела находится меньше способов применения, в) привычка полагаться на абстракции и не обращать внимание на детали г) перестают изучать что-то действительно новое (постепенно теряется навык учиться).
Что делать чтобы поддерживать мозги в форме на протяжении всей жизни:
правильное питание (фрукты, овощи, красное вино и т.п.);
регулярная физическая активность;
«социальные упражнения»;
тренировка мозгов: освоить музыкальный инструмент, выучить еще один язык и т.д. (но желательно не слишком отстраненное от физической реальности).
Для меня, в период повышенной нагрузки, залогом «успешного» сна выступает расслабление. Так получилось что для расслабления я использую одну из практик йогов. Называется она Шавасана или поза «мертвого». Сама эта практика имеет несколько этапов освоения. Все зависит от того насколько у человека хватит заинтересованности и терпения. По себе могу сказать что и освоение техники для начинающих дает довольно ощутимые результаты. Крайне желательно освоить ее до 4 фазы (см. ссылку), но из-за лени я остановился на технике для начинающих.
Сами йоги утверждают что при идеальном исполнении 10 минут Шавасаны заменяют 4-х часовой сон. Но достижение этого идеального исполнения тоже нелегкая задача.
В интернете много ссылок с описанием этой техники, но они в основном для начинающих. Я бы посоветовал обратить внимание на более подробные описания. Например вот такое описание: narmed.ru/articles/joga/hatha/rasslabl01
> Почему после коммита обоих в build появится только один? Наоборот при коммите изменения сольются.
> А если не сольются, то второму надо будет сначала апдейт сделать, потом конфликты поправить.
согласен. немного стормозил. изменения сольются, но в любом случае если использовать предложенный post-хук это будет не так удобно делать (я имею в виду svn update перед коммитом в build).
> Репозитарий на всех один. Программист и верстальщик просто сделали checkout в свои личные директории.
> То, что вы называете project.example.com/branches/username есть почти то же самое, что и
> username.project.example.com/trunk. За исключением того, что в первом случае в репозитарии уже лежит
> модифицированный код, который надо сливать с основным проектом.
> А во втором случае модифицированный код лежит пока у конкретного программиста и ему нужно сделать commit в
> общую ветку.
Странно как-то у вас написано. В первом случае вы говорите про репозитарий, а во втором сравниваете с рабочей копией. Я вроде так и не говорил никогда. Насколько я понял не важно как обращаешься к проекту
pr1.project.example.com/trunk или pr2.project.example.com/trunk получаешь в рабочую копию данные из одного репозитория?
Если это так, то я не понимаю фразу из статьи:
— У себя, внутри студии, мы выбрали следующую схему:
username.project.example.com/trunk
По такому адресу сам разработчик и все члены команды получают доступ к наработкам друг друга.
—
Теперь допустим программист pr1 добавляет в проект некоторую функциональность, допустим новостную ленту. Когда дело доходит до представления ( шаблонов), то на начальном этапе программист сам этим занимается. Но в какой-то момент подключается верстальщик m1. Видимо он должен извлечь некоторые наработки программиста pr1 ( а если еще и pr2 работал на этой же функциональностью, то и как-то merge сделать) себе в рабочую копию. Хотя он конечно может извлечь все из интеграционного проекта build.
Но вот что мне не нравится больше всего, при продолжении работы программист и верстальщик делают commit и в интеграционном проекте build будут последние изменения сделанные кем-либо из pr1, m1. Это усложняет совместную разработку.
Мне пока больше нравиться идея, когда.
Есть проект. В нем есть trunk — основное направление разработки. Все пользователи извлекают для свой работы рабочую копию из trunk, кроме специальных случаев. commit они тоже туда делают.
Таким образом нет username.project.example.com/trunk, а есть project.example.com/trunk и в редких случаях project.example.com/branches/username (его «нужно» потом объединять с основной веткой разработки).
Это не значит что нельзя автоматизировать просмотр извлеченных рабочий копий для каждого пользователя. Как вариант в домашнем каталоге пользователя есть каталог projects. Туда пользователь извлекает из SVN рабочую копию проекта и apache автоматически подхватывает его по адресу username.project.example.com
Но при этом всегда есть, актуальная что-ли, версия проекта.
Еще в вашем описании среды никак не описана БД. Многие проекты ее используют. Понятно что для каждого из пользователей необходима свою БД.
В любом случае я ваш метод не критикую, просто сейчас в нашей компании пытаемся внести большую организацию в веб-разработку и ваша статья очень кстати. И никак не могу переложить на наши внутренние процессы вашу организацию. :(
Просто именно описание того что есть некоторый магический build.example.com не было в статье. И я хотел узнать как у вас это делается.
Спасибо за ответ.
Каждый пользователь делает commit куда-то сюда, в зависимости от ситуации:
username.project.example.com/trunk
username.project.example.com/tags
username.project.example.com/branches
А как они будут делать update?
Ведь у них независимые по сути проекты.
Просто я видел немного другую организацию хранения проекта:
project.example.com/trunk
project.example.com/tags
project.example.com/branches/username1
project.example.com/branches/username2
Т.е. идея в том, что есть один проект и над ним работают разные люди. При этом конфигурирование доступа для конкретной реализации проекта в Apache можно также автоматизировать.
У меня вот какой вопрос возник.
Допустим над проектом (project1) работают два программиста (pr1, pr2) и один верстальщик (m1), т.е. получается что каждый из пользователей получит свой каталог проекта, что-то такое:
/var/www/pr1.example.com/project1/
/var/www/pr2.example.com/project1/
/var/www/m1.example.com/project1/
Но существует ли в этой схеме вариант увидеть общий итог работы этих трех?
Т.е. когда их частные изменения собираются вместе.
Допустим работа верстальщика m1 добавляется к работе программиста pr1.
Может они самостоятельно, с помощью SVN, подгоняют свои проекты под этот общий итог?
Возможно я не совсем разобрался в самой идее и поэтому надеюсь на вашу помощь.
А так, со стороны, кажется что ДЛЯ НИХ memcached лишний.
Думаю точность там может быть не такая как у специализированного аппарата, но у него и цель другая.
Ну и когда ты задачу берешь в работу то там фиксируется время. От него потом легко произвести вычисления.
Чтобы контроллер домена поднять вообще особо не надо напрягаться. А если что-то сломается, то все легко и самостоятельно
исправится.
:)))
Мы вот тут недавно вызывали себе администратора для установки Windows Server 2012. Он там немного завис. Говорил что немного поменялось все. Меня лично порадовал на сервере стартовый экран в стиле Метро.
:))
У нас в конторе пока «пачка разных ОСей». В первую очередь дизайнеры сидят под виндой. Остальных потихоньку двигаем в сторону линукса.
Довольно приятно читается.
Для парсинга мы применяем компоненту из фреймворка Symfony (http://components.symfony-project.org/yaml/).
Результат кешируем в виде php кода.
После сохранения результата в кеш быстродействие будет сравнимо с хранением конфигов в виде обычного PHP.
Лично мне тоже тяжеловато на слух воспринимать такую лекцию. Но там еще иногда показывают схемы и это улучшает восприятие.
Один мой знакомый, побывав на одной из лекций Google Tech Talk, сделал вот какие для себя выдержки (далее я сохранил его грамматику):
Я к тому все это клоню, что на развитие пластичности мозга очень не плохо влияет освоение музыкального инструмента.
Ну и ссылка на эту лекцию в Google:
www.youtube.com/watch?v=UyPrL0cmJRs
Для меня, в период повышенной нагрузки, залогом «успешного» сна выступает расслабление. Так получилось что для расслабления я использую одну из практик йогов. Называется она Шавасана или поза «мертвого». Сама эта практика имеет несколько этапов освоения. Все зависит от того насколько у человека хватит заинтересованности и терпения. По себе могу сказать что и освоение техники для начинающих дает довольно ощутимые результаты. Крайне желательно освоить ее до 4 фазы (см. ссылку), но из-за лени я остановился на технике для начинающих.
Сами йоги утверждают что при идеальном исполнении 10 минут Шавасаны заменяют 4-х часовой сон. Но достижение этого идеального исполнения тоже нелегкая задача.
В интернете много ссылок с описанием этой техники, но они в основном для начинающих. Я бы посоветовал обратить внимание на более подробные описания. Например вот такое описание: narmed.ru/articles/joga/hatha/rasslabl01
И вот такая ссылочка, на мой взгляд, будет поприятнее для первоначального знакомства.
components.symfony-project.org/event-dispatcher/
> А если не сольются, то второму надо будет сначала апдейт сделать, потом конфликты поправить.
согласен. немного стормозил. изменения сольются, но в любом случае если использовать предложенный post-хук это будет не так удобно делать (я имею в виду svn update перед коммитом в build).
> Репозитарий на всех один. Программист и верстальщик просто сделали checkout в свои личные директории.
> То, что вы называете project.example.com/branches/username есть почти то же самое, что и
> username.project.example.com/trunk. За исключением того, что в первом случае в репозитарии уже лежит
> модифицированный код, который надо сливать с основным проектом.
> А во втором случае модифицированный код лежит пока у конкретного программиста и ему нужно сделать commit в
> общую ветку.
Странно как-то у вас написано. В первом случае вы говорите про репозитарий, а во втором сравниваете с рабочей копией. Я вроде так и не говорил никогда. Насколько я понял не важно как обращаешься к проекту
pr1.project.example.com/trunk или pr2.project.example.com/trunk получаешь в рабочую копию данные из одного репозитория?
Если это так, то я не понимаю фразу из статьи:
— У себя, внутри студии, мы выбрали следующую схему:
username.project.example.com/trunk
По такому адресу сам разработчик и все члены команды получают доступ к наработкам друг друга.
—
Мне просто не очень понравилась идея хуков.
Вот некоторый пример.
Пусть все будет как и описано в этом комменте ( habrahabr.ru/blogs/webdev/65005/#comment_1815206 )
Теперь допустим программист pr1 добавляет в проект некоторую функциональность, допустим новостную ленту. Когда дело доходит до представления ( шаблонов), то на начальном этапе программист сам этим занимается. Но в какой-то момент подключается верстальщик m1. Видимо он должен извлечь некоторые наработки программиста pr1 ( а если еще и pr2 работал на этой же функциональностью, то и как-то merge сделать) себе в рабочую копию. Хотя он конечно может извлечь все из интеграционного проекта build.
Но вот что мне не нравится больше всего, при продолжении работы программист и верстальщик делают commit и в интеграционном проекте build будут последние изменения сделанные кем-либо из pr1, m1. Это усложняет совместную разработку.
Мне пока больше нравиться идея, когда.
Есть проект. В нем есть trunk — основное направление разработки. Все пользователи извлекают для свой работы рабочую копию из trunk, кроме специальных случаев. commit они тоже туда делают.
Таким образом нет username.project.example.com/trunk, а есть project.example.com/trunk и в редких случаях project.example.com/branches/username (его «нужно» потом объединять с основной веткой разработки).
Это не значит что нельзя автоматизировать просмотр извлеченных рабочий копий для каждого пользователя. Как вариант в домашнем каталоге пользователя есть каталог projects. Туда пользователь извлекает из SVN рабочую копию проекта и apache автоматически подхватывает его по адресу username.project.example.com
Но при этом всегда есть, актуальная что-ли, версия проекта.
Еще в вашем описании среды никак не описана БД. Многие проекты ее используют. Понятно что для каждого из пользователей необходима свою БД.
В любом случае я ваш метод не критикую, просто сейчас в нашей компании пытаемся внести большую организацию в веб-разработку и ваша статья очень кстати. И никак не могу переложить на наши внутренние процессы вашу организацию. :(
Спасибо за ответ.
username.project.example.com/trunk
username.project.example.com/tags
username.project.example.com/branches
А как они будут делать update?
Ведь у них независимые по сути проекты.
Просто я видел немного другую организацию хранения проекта:
project.example.com/trunk
project.example.com/tags
project.example.com/branches/username1
project.example.com/branches/username2
Т.е. идея в том, что есть один проект и над ним работают разные люди. При этом конфигурирование доступа для конкретной реализации проекта в Apache можно также автоматизировать.
Допустим над проектом (project1) работают два программиста (pr1, pr2) и один верстальщик (m1), т.е. получается что каждый из пользователей получит свой каталог проекта, что-то такое:
/var/www/pr1.example.com/project1/
/var/www/pr2.example.com/project1/
/var/www/m1.example.com/project1/
Но существует ли в этой схеме вариант увидеть общий итог работы этих трех?
Т.е. когда их частные изменения собираются вместе.
Допустим работа верстальщика m1 добавляется к работе программиста pr1.
Может они самостоятельно, с помощью SVN, подгоняют свои проекты под этот общий итог?
Возможно я не совсем разобрался в самой идее и поэтому надеюсь на вашу помощь.
Не думаю что TAR сможет что-то тут «сжать». Он не для этого обычно используется. :)
В данном случае, когда файл один, можно сразу переходить к gzip-у.