Сам сейчас с этим разбираюсь и хотел у вас уточнить.
1) По настройкам видно что loki будет сохранять свои данные в папках /loki/chunks и /loki/rules Я не вижу чтобы для этого были подготовлены volume в docker-compose. Что-то типа: volumes: - ./volumes/loki:/loki
Разве не получится что при перезапуске loki данные из этих папок будут потеряны? Возможно это нормально? Но ведь хранилища могут быть разные. Например S3. Там же такого поведения не будет.
Я тоже так и не смог понять, зачем может понадобиться такая связка 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, подгоняют свои проекты под этот общий итог?
Возможно я не совсем разобрался в самой идее и поэтому надеюсь на вашу помощь.
Сам сейчас с этим разбираюсь и хотел у вас уточнить.
1) По настройкам видно что loki будет сохранять свои данные в папках /loki/chunks и /loki/rules
Я не вижу чтобы для этого были подготовлены volume в docker-compose.
Что-то типа:
volumes:- ./volumes/loki:/loki
Разве не получится что при перезапуске loki данные из этих папок будут потеряны?
Возможно это нормально? Но ведь хранилища могут быть разные. Например S3. Там же такого поведения не будет.
2) Настройка лимитов через table manager. В официальной документации говорят что Table Manager (deprecated)
https://grafana.com/docs/loki/latest/configure/storage/
А так, со стороны, кажется что ДЛЯ НИХ 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-у.