Более того, даже в небольших по размеру городах периодически приходится ехать в незнакомое место или в редко посещаемое, куда забываешь как добраться к моменту возникновения нужды. Ну про пребывание в незнакомом городе говорить я думаю смысла нет, тут и так всё понятно.
Аналогично. Есть определённая сумма, которую знаю на сколько примерно должно хватать. Снимаю её только тогда, когда кончается предыдущая порция. Если вижу, что порция уходит слишком быстро, то урезаю её расход, если же наоборот вышла экономия, то можно позволить себе «расслабиться» и побаловать. При этом месяц — это несколько порций, так более точно можно регулировать процесс. Порция тратится на повседневные нужды: магазины, обеды и пр. Экономия обычно уходит на кино, кафе и прочие заведения. Т.е. дополнительная самостимуляция контролировать простые траты, чтобы позволить себе приятно :)
А вот у меня наоборот всё. Супруга — ещё тот экономист. Она реально умеет копить деньги, а я вроде-бы умею их правильно тратить. Вот и получается что она контролирует меня, а я не даю ей складывать всё «в газетку» и пускаю деньги в «оборот». Так сказать пользуемся плюсами друг дргуа, причём оба это понимаем.
Что значит «перетирается в следующий раз»? Хранилище у stash организовано на основе стека. И при очередном git stash мы добавляем в стек новое состояние. И если не чистить stash, то стек будет только расти.
Ну т.е. всётаки программист пишет перловый скрипт и какую-то часть конфига nginx. Админ потом это всё раскладывает с очередным релизом, при необходимости люди коммуницируют делают что-то совместно, либо кто-то кому-то ставит задачу что нужно что-то сделать.
На самом деле подход очень интересный и его стоит посмотреть с разных сторон.
Что касается проблем: первое что уже видится сейчас это перенос логики в другую «подсистему». Получается так что у нас есть php-программист который может сделать реализацию на php. Но мы уже начинаем писать a) на perl б) на стороне nginx. Ладно, пусть язык программирования не важен, но вот вроде за nginx отвечает системный администратор. Вопрос — кто должен отвечать за код на стороне nginx?
С одной стороны программист — ему же нужно напистаь код, выполняющий задачу. С другой — админ, ведь это же его часть и он за неё отвечает. А что если нужно будет менять реализацию, править там что-то?
Правит программист — админ не в курсе правок. Правит админ — программист не в курсе. Симбиоз? Совместно?
Вот тут пока не понятно как быть. Давайте порассуждаем?
Скажите, а для отлова утечек вы используете только стандартные средства хрома или что-то ещё?
И я правильно понимаю что вы скрупулёзно, в силу требований проекта, проверяете на утечки новые куски кода?
Саня, присоединяюсь к поздравлениям!
Процесс написания книги чем-то похож на процесс разработки крупного проекта не находишь? :) Девелопмент, код-ревью, рефакторинг, тестирование, багфиксинг, RC1..n, релиз.
В одном из проектов тоже столкнулся с проблемой определения кодировки приходящего текста.
В багтрекере PHP даже баг заведён по этому поводу: bugs.php.net/bug.php?id=38138
А для проверки кодировки текста я бы рекоммендовал использовать функцию mb_check_encoding(). Она работает достаточно адекватно. По крайней мере мои проверки (UTF-8, Windows-1251, KOI8-R, ISO-8859-5) не выявили проблем. В принципе на основе этой функции также можно написать небольшой велосипедик по определению самых распространённых кодировок.
Внутрь исходников расширения mbstring не заглядывал, но теперь стало интересно как работает вышеназванная mb_check_encoding. Вполне возможно там могут использоваться те же функции что и в md_detect_encoding, тогда на надёжность работы уже полагаться не придётся. Надо бы проверить.
От Чпок поинтов под вечер руки просто просились отдохнуть.
Кофе + вкуснейшая выпечка это очень здорово заправляло в течении дня и не давало заглохнуть организму.
Всем выступавшим огромное спасибо! Да, были накладки и неровности, но преимущества от полученной полезной информации и общения с профессионалами перевесили всё! Цели для ковырятельств в недрах намечены, дальнейшие вехи профессионального роста обозначены.
Очень был рад увидеть всех своих бывших и нынешних коллег, пообщаться с однокурсниками (с удивлением был рад вас обнаружить на конференции).
Зверское чудо получится: на Си пишем код, который транслируется в PHP, который в свою очередь будет обрабатываться интерпретатором PHP написанным на Си. Забавно, не правда ли?
Что касается проблем: первое что уже видится сейчас это перенос логики в другую «подсистему». Получается так что у нас есть php-программист который может сделать реализацию на php. Но мы уже начинаем писать a) на perl б) на стороне nginx. Ладно, пусть язык программирования не важен, но вот вроде за nginx отвечает системный администратор. Вопрос — кто должен отвечать за код на стороне nginx?
С одной стороны программист — ему же нужно напистаь код, выполняющий задачу. С другой — админ, ведь это же его часть и он за неё отвечает. А что если нужно будет менять реализацию, править там что-то?
Правит программист — админ не в курсе правок. Правит админ — программист не в курсе. Симбиоз? Совместно?
Вот тут пока не понятно как быть. Давайте порассуждаем?
И я правильно понимаю что вы скрупулёзно, в силу требований проекта, проверяете на утечки новые куски кода?
Процесс написания книги чем-то похож на процесс разработки крупного проекта не находишь? :) Девелопмент, код-ревью, рефакторинг, тестирование, багфиксинг, RC1..n, релиз.
В багтрекере PHP даже баг заведён по этому поводу: bugs.php.net/bug.php?id=38138
А для проверки кодировки текста я бы рекоммендовал использовать функцию mb_check_encoding(). Она работает достаточно адекватно. По крайней мере мои проверки (UTF-8, Windows-1251, KOI8-R, ISO-8859-5) не выявили проблем. В принципе на основе этой функции также можно написать небольшой велосипедик по определению самых распространённых кодировок.
Внутрь исходников расширения mbstring не заглядывал, но теперь стало интересно как работает вышеназванная mb_check_encoding. Вполне возможно там могут использоваться те же функции что и в md_detect_encoding, тогда на надёжность работы уже полагаться не придётся. Надо бы проверить.
Кофе + вкуснейшая выпечка это очень здорово заправляло в течении дня и не давало заглохнуть организму.
Всем выступавшим огромное спасибо! Да, были накладки и неровности, но преимущества от полученной полезной информации и общения с профессионалами перевесили всё! Цели для ковырятельств в недрах намечены, дальнейшие вехи профессионального роста обозначены.
Очень был рад увидеть всех своих бывших и нынешних коллег, пообщаться с однокурсниками (с удивлением был рад вас обнаружить на конференции).
Спасибо организации за подобный фест!