Не возникало желания пользоваться чем-то одним?
Я в конечном счёте всё взаимодействие с Git'ом стащил в консоль.
Вариант для проформы можно было оставить, конечно, но я понадеялся на решительность в выборе :) Воздержаться — как вариант.
Просмотр и визуализация, если Вы о diff'ах всяких и графах по логу, всё равно делаются какими-то другими утилитами.
Я скорее о рядовых операциях — add, commit, push etc. Вряд ли ведь, скажем, commit делается через раз то оттуда, то оттуда?
Пользовательское меню в Far — это, скажем, «воздержаться» :-)
Мне нравится в них разрешать конфликты. Мержилка действительно достаточно приятная.
В остальном как-то непонятно.
Например, работа со стейджингом, видимо, принесена в жертву в пользу тех, кто переходит с SVN и ещё не читал Pro Git :)
Несмотря на то, что SVN я почти всегда использовал из IDE, Git'ом пользуюсь только из консоли. Возможно, потому что пока у графических клиентов не получается вобрать в себя всю магию, которую предоставляет Git; возможно, потому что не всегда удаётся угадать, что сделает эта графическая монстра — «какие именно понятные команды выполнит эта непонятная кнопка», возможно, по каким-то другим, более скрытым причинам. Вот их бы, причины, и хотелось увидеть в комментариях.
1. Почему не работал сборщик сессий?
Проверьте значения session.gc_probability и session.gc_divisor в php.ini. Два этих параметра вместе определяют вероятность, с которой сборщик сессий запустится перед выполнением очередного запроса (session.gc_probability/session.gc_divisor).
Дело в том, что в дебиане и производных по умолчанию числитель этой дроби установлен в ноль, соответственно, сборщик сессий не запустится никогда.
Вместо этого имеем /etc/cron.d/php5:
То есть всё это делается не средствами php, а просто find -delete, запускаемым по расписанию. Такой вот debian-way.
У себя на серверах, где хостится, например, много тестовых сайтов, я пишу сессии в пользовательские директории /srv/www/*/tmp и точно так же хожу по ним уже своим аналогичным cronjob'ом.
2. Рекомендую innodb_file_per_table. Без этой опции все данные из всех InnoDB-таблиц валятся в файл %DATADIR%/ibdata1. Этот файл, кроме всего прочего, никогда не уменьшается в размере.
В один прекрасный день один прекрасный разработчик записал в одну прекрасную InnoDB-таблицу порядка сотни гигов блобов. Потом-то, конечно, он их удалил, а вот ibdata1 так и остался распухшим. Высвободить место я смог только перезаливкой баз (запустил два экземпляра mysql, один смотрел в старый datadir — на нём делался mysqldump, другой — в новый datadir и в него этот дамп сразу же и вливался). В общем, получилось грустно и печально.
Всё правильно.
Именно поэтому давайте, скрестя пальцы и скрепя сердце, следить за распилом на DPI, поднимать VPN и обоснованно ждать, что этим дело ВеликихОгненныхСтен™ и закончится.
Тот мой комментарий на втором уровне — не больше, чем шутка-трололо. К нему не стоит относиться серьёзно.
Это [не настолько техническая] шутка, в которой, возможно только доля шутки. Ну вот давайте посмотрим, как может начать всё это дело развиваться.
Допустим, эта вдумчивая инспекция пакетов поначалу всех устроила. Людям, не имеющим специфических знаний, всё равно про те шифрования и випиэны с ходу ничего неизвестно. В то же время эти знания начинают распрстраняться в виде инструкций для чайников типа «Установка шифрованного VPN-соединения для обхода сраных фильтров». Когда авторы догоняют, что их нововведение перестало работать, они запрещают шифроваться вообще без специально выдаваемого разрешения (с применением шифрования же этот DPI не очень-то полезен, если я правильно понимаю, что он делает?). Ну, разрешат использовать там https для российских интернет-банков и ещё каких-нибудь по заявлению. Потом введут, скажем, уголовную ответственность за туннели в другие страны (в Китае же уже сейчас нельзя, да?). SSH? Ну, тоже по спецразрешению.
Вообще говоря, я считаю, что ввиду того, что интернет воспринимает цензуру как помеху на линии, мы имеем 2 крайности: или не выделываться и не пытаться фильтровать нефильтруемое, или просто запрещать всё под ответственность самого пользователя, особо не парясь и именя возможность в любой момент провести нерадивого пользователя по удобной статье. И тут уже кому на что мудрости хватит.
transmission запускается как демон без костылей. Под него есть готовые клиенты. Умеет он не меньше, чем rtorrent.
Я вот пару недель назад-таки нашёл в себе силы и отправил rtorrent на пенсию :)
Модули Apache можно добавлять и исключать, ставя галочку в соответствующем чекбоксе. Это позволяет лучше управлять потреблением RAM на каждом сервере и тем самым повысить плотность VPS на ноду.
И сильно повысилась плотность VPS на ноду при снятии нескольких галочек? :-)
«Подходы к визуализации информации».
«Способы визуализации информации».
«Формы визуализации информации».
Принципы, опять же.
При желании, наверно, можно было выбрать синоним по вкусу. Тем более, что тут термин «паттерн» не насколько устоявшийся, как в ООП, например.
Лучше так: подходите к кассе, лежит кошелёк. Взяли посмотреть (хотели вернуть владельцу? пересчитать содержимое и потом решить? стырить безусловно?), а тут оппа — и на восемь месяцев, потому что в кошельке были две «визы», чьи номера и CVV Вы, безусловно, могли видеть, пока решали отдать ли кошелёк владельцу.
Проявили любопытство и хотели проявить гражданскую сознательность? Нет, взломали чужой кошелёк.
Именно в свете вышеизложенного мне нынешние правила пользования всяческими ресурсами кажутся как минимум глупыми (подставил кавычку в форму поиска? за тобой уже выехали!)
Зачем сравнивать это с nginx_uploadprogress_module, если при наличии nginx в качестве реверс-прокси предложенное решение всё равно работать не будет? Реверс-прокси плюнет в бекэнд запросом, когда он полностью получен, то есть с точки зрения php файл загрузится чуть ли не мгновенно.
То есть это едва ли подходит для массового использования на неопределённых хостингах, которые тоже всё чаще ставят реверс-прокси. То есть подходит только чтобы порадовать заказчика какой-нибудь закрытой системы, которую наверняка не завалит толпа тушканчиков и для загрузки файлов, например, можно обойтись без реверс-прокси.
Чтобы не холиварить: хорошо, что такая возможность появилась. Плохо, что возможность её реального применения под большим вопросом. А сравнение с nginx_uploadprogress_module вообще, имхо, не совсем корректно потому что это, по сути, взаимоисключающие явления.
Вряд ли почасовые ставки программистов или верстальщиков кому-то помогут, причем как из-за расплывчатого представления заказчика о затраченном времени специалиста, так и из-за проблем с управлением своим временем у самих «молодых амбициозных команд».
Вообще говоря, я бы предложил подробное описание проектов в портфолио с примерным раскладом что к чему и что почём. Такой подход может опять-таки расположить клиента к «открытой» студии.
Поскольку я не претендовал на включение моего модуля в дистрибутив, я позволил себе некоторые вольности.
Тут нужно или трусы надеть, или крестик снять.
Если 'в Kohana' — то можно было расширить (или заново реализовать), файловый кеш который уже существует, прикрутив к нему теги (как справедливо предложил dohlik), до кучи переступив через себя и приведя код в соответствие с принятыми в сообществе стандартами.
Если нет — слово Kohana скорее лишнее. Тем более, что в предлагаемом классе используется разве что конфиг, который из зависимостей при большом желании выпиливается ну просто на раз-два.
Небольшая ремарка. Сами кохановцы делают зависимость от конфига ещё более слабой, обратите внимание. Обращение к классу Config (или прокси Kohana::config) используется в основном только во вспомогательных статических методах, которые передают уже полученный конфиг в виде массива в конструктор.
К примеру, автоматическое форматирование кода в NetBeans нарушает куда больше пунктов этого соглашения, чем нарушил я.
Не настроенное под конкретную ситуацию автоформатирование.
Не надо сваливать на настройки IDE, поставляемые с ней по умолчанию.
Я в конечном счёте всё взаимодействие с Git'ом стащил в консоль.
Вариант для проформы можно было оставить, конечно, но я понадеялся на решительность в выборе :) Воздержаться — как вариант.
Я скорее о рядовых операциях — add, commit, push etc. Вряд ли ведь, скажем, commit делается через раз то оттуда, то оттуда?
Пользовательское меню в Far — это, скажем, «воздержаться» :-)
В остальном как-то непонятно.
Например, работа со стейджингом, видимо, принесена в жертву в пользу тех, кто переходит с SVN и ещё не читал Pro Git :)
1. Почему не работал сборщик сессий?
Проверьте значения
session.gc_probabilityиsession.gc_divisorвphp.ini. Два этих параметра вместе определяют вероятность, с которой сборщик сессий запустится перед выполнением очередного запроса (session.gc_probability/session.gc_divisor).Дело в том, что в дебиане и производных по умолчанию числитель этой дроби установлен в ноль, соответственно, сборщик сессий не запустится никогда.
Вместо этого имеем
/etc/cron.d/php5:То есть всё это делается не средствами php, а просто find -delete, запускаемым по расписанию. Такой вот debian-way.
У себя на серверах, где хостится, например, много тестовых сайтов, я пишу сессии в пользовательские директории
/srv/www/*/tmpи точно так же хожу по ним уже своим аналогичным cronjob'ом.2. Рекомендую
innodb_file_per_table. Без этой опции все данные из всех InnoDB-таблиц валятся в файл%DATADIR%/ibdata1. Этот файл, кроме всего прочего, никогда не уменьшается в размере.В один прекрасный день один прекрасный разработчик записал в одну прекрасную InnoDB-таблицу порядка сотни гигов блобов. Потом-то, конечно, он их удалил, а вот
ibdata1так и остался распухшим. Высвободить место я смог только перезаливкой баз (запустил два экземпляра mysql, один смотрел в старый datadir — на нём делался mysqldump, другой — в новый datadir и в него этот дамп сразу же и вливался). В общем, получилось грустно и печально.Именно поэтому давайте, скрестя пальцы и скрепя сердце, следить за распилом на DPI, поднимать VPN и обоснованно ждать, что этим дело ВеликихОгненныхСтен™ и закончится.
Тот мой комментарий на втором уровне — не больше, чем шутка-трололо. К нему не стоит относиться серьёзно.
Допустим, эта вдумчивая инспекция пакетов поначалу всех устроила. Людям, не имеющим специфических знаний, всё равно про те шифрования и випиэны с ходу ничего неизвестно. В то же время эти знания начинают распрстраняться в виде инструкций для чайников типа «Установка шифрованного VPN-соединения для обхода сраных фильтров». Когда авторы догоняют, что их нововведение перестало работать, они запрещают шифроваться вообще без специально выдаваемого разрешения (с применением шифрования же этот DPI не очень-то полезен, если я правильно понимаю, что он делает?). Ну, разрешат использовать там https для российских интернет-банков и ещё каких-нибудь по заявлению. Потом введут, скажем, уголовную ответственность за туннели в другие страны (в Китае же уже сейчас нельзя, да?). SSH? Ну, тоже по спецразрешению.
Вообще говоря, я считаю, что ввиду того, что интернет воспринимает цензуру как помеху на линии, мы имеем 2 крайности: или не выделываться и не пытаться фильтровать нефильтруемое, или просто запрещать всё под ответственность самого пользователя, особо не парясь и именя возможность в любой момент провести нерадивого пользователя по удобной статье. И тут уже кому на что мудрости хватит.
Я вот пару недель назад-таки нашёл в себе силы и отправил rtorrent на пенсию :)
И сильно повысилась плотность VPS на ноду при снятии нескольких галочек? :-)
«Способы визуализации информации».
«Формы визуализации информации».
Принципы, опять же.
При желании, наверно, можно было выбрать синоним по вкусу. Тем более, что тут термин «паттерн» не насколько устоявшийся, как в ООП, например.
Проявили любопытство и хотели проявить гражданскую сознательность? Нет, взломали чужой кошелёк.
Именно в свете вышеизложенного мне нынешние правила пользования всяческими ресурсами кажутся как минимум глупыми (подставил кавычку в форму поиска? за тобой уже выехали!)
Автор выбросил непонятный символ? :)
Вряд ли.
То есть это едва ли подходит для массового использования на неопределённых хостингах, которые тоже всё чаще ставят реверс-прокси. То есть подходит только чтобы порадовать заказчика какой-нибудь закрытой системы, которую наверняка не завалит толпа тушканчиков и для загрузки файлов, например, можно обойтись без реверс-прокси.
Чтобы не холиварить: хорошо, что такая возможность появилась. Плохо, что возможность её реального применения под большим вопросом. А сравнение с nginx_uploadprogress_module вообще, имхо, не совсем корректно потому что это, по сути, взаимоисключающие явления.
Вообще говоря, я бы предложил подробное описание проектов в портфолио с примерным раскладом что к чему и что почём. Такой подход может опять-таки расположить клиента к «открытой» студии.
Тут нужно или трусы надеть, или крестик снять.
Если 'в Kohana' — то можно было расширить (или заново реализовать), файловый кеш который уже существует, прикрутив к нему теги (как справедливо предложил dohlik), до кучи переступив через себя и приведя код в соответствие с принятыми в сообществе стандартами.
Если нет — слово Kohana скорее лишнее. Тем более, что в предлагаемом классе используется разве что конфиг, который из зависимостей при большом желании выпиливается ну просто на раз-два.
Небольшая ремарка. Сами кохановцы делают зависимость от конфига ещё более слабой, обратите внимание. Обращение к классу Config (или прокси Kohana::config) используется в основном только во вспомогательных статических методах, которые передают уже полученный конфиг в виде массива в конструктор.
Не настроенное под конкретную ситуацию автоформатирование.
Не надо сваливать на настройки IDE, поставляемые с ней по умолчанию.