• PHP: изменение стуктуры БД в командной разработке
    0
    А про добавление колонок на больших таблицах — здесь хорошо описано:
    Опыт 1440 миграций баз данных — habr.com/company/wrike/blog/414441
    Колонка добавляется как nullable ну и дальше аккуратно заполняется.
  • PHP: изменение стуктуры БД в командной разработке
    0
    Обычно делаем CREATE INDEX CONCURRENTLY — PG создает индекс без блокировки таблицы в реалтайме. Ну и медленнее он работает конечно.
  • PHP: изменение стуктуры БД в командной разработке
    0
    Интересно, сможете показать исходники export?
  • PHP: изменение стуктуры БД в командной разработке
    0
    А как вы это делаете?
  • PHP: изменение стуктуры БД в командной разработке
    0
    Да, подходящий кейс
  • PHP: изменение стуктуры БД в командной разработке
    +1
    Когда проекту больше 5 лет и миграций за тысячу — как-то по другому надо
  • PHP: изменение стуктуры БД в командной разработке
    +1
    ORM в миграциях нужна не столько для «удобства», сколько для потенциальной возможности смены СУБД

    В миграциях этого точно не нужно — они одноразовые.

    Транзакции в DDL

    НЕ все базы поддерживают транзакции на уровне запросов по изменению структуры БД.
    Долго работал и мучался с MySQL, у которой этого не было. Как там сейчас уже не в теме.
  • Юзабилити-тестирование на коленке
    0
    А много не надо. Человек 4-6 за один раунд, а потом анализировать, пилить, и снова тестировать.
  • Юзабилити-тестирование на коленке
    0
    Репо приватный. Выложил сценарий в gist: https://gist.github.com/715534
  • Юзабилити-тестирование на коленке
    0
    Естественно надо подбирать целевую аудиторию. Но это, конечно, может быть не просто, если ваша аудитория топ-менеджеры, например. Но всегда можно что-то придумать.
  • Юзабилити-тестирование на коленке
    +2
    На сценарии? Я не давал ссылку на сценарии? В посте я только опубликовал один кейс для примера. Или я что-то не понял?
  • Почему Git
    0
    Вот именно, что впечатления. Жду полноценный обзор :)
  • Почему Git
    0
    Точно, сейчас проверил. Там нумерованные стеши. То ли я что-то перепутал, то ли разработчики что-то поменяли. Я редко использую больше одного стеша.
  • Почему Git
    0
    Я бы еще добавил неудобство работы с субмодулями, у которых тоже есть субмодули со своими субмодулями.
  • Почему Git
    0
    Git-way: один модуль — один репозиторий. Можно конечно объедить группу репозиториев в суперрепозиторий, но обновляться будет не совсем удобно. Не пробовал.
    Или положите все в один репозиторий и подключайте ко всем проектам. Я надеюсь ваше приложение позволяет хранить модули, которые не используются.
  • Почему Git
    0
    Давайте заканчивать с пустыми папками. Воспринимайте это как данность. Никто еще не умер от этого.
    Пустые папки создаются только один раз при разворачивании проекта. А если вы это регулярно делаете, тогда это вопрос организации сборки и деплоя.
  • Почему Git
    0
    git stash save «my stash name»
  • Почему Git
    +2
    > 7$ в месяц 5 закрытых репозиториев и 600Мб (да ещё трудности с оплатой, только кредиткой)
    Я плачу 200 руб в мес и не напрягаюсь. Кредитка? Это разве проблема?
    Можно сделать по-другому: положить репо на публичный сервер и ходить к нему по SSH.

    И как-то непонятно у вас организована командная работа. Я не могу оценить, но думаю, что можно сделать лучше.
  • Почему Git
    0
    > А топик «Git vs Hg» будет очевидно однобок
    А ты все равно напиши с соответствующим дисклеймером. По крайней мере я смогу оценить его с точки зрения Git и оценить его (git) слабые стороны.
  • Почему Git
    0
    Да. У каждого СВОЙ локальный репозиторий со всей историей.
    И центральный репозиторий — это не больше чем соглашение, что конкретно именно эта копия будет использоваться для обмена.
  • Почему Git
    0
    Вся децентрацизация крутится вокруг обмена патчами:
    — Положите bare-репозиторий на публичный сервер и обменивайтесь информацией через него.
    — Можно работать с системой форков, как это устроено на GitHub — здесь неограниченная связь многие ко многим.
    — Можно коннектиться напрямую через SSH. Это может быть оправдано, когда вас всего двое.
    — Можно обмениваться патчами по почте: git format-patch, git send-email, git apply или git am

    Все зависит от того, как у вас организована работа в команде. Наиболее простой и удобный способ — это выделить один репозиторий для обмена. А уж комбинировать все указанные выше способы вы можете как угодно в соответствии с потребностями.
  • Почему Git
    +1
    Это махровая безграмотность :)
  • Почему Git
    0
    У меня есть аналогичный проект, занимает 100М. Git репозитарий со всей историей занимает не на много больше.
  • Почему Git
    0
    > вы пробовали пользоваться другими DVCS
    Нет не довелось, а на экперименты у меня нет возможностей. Хотя, раз пошла такая пьянка, подниму небольшой проектик на чем-нибудь еще. Но git меня устраивает дальше некуда.

    > за использование — оторвать руки по колени. думать нужно, прежде чем коммититься.
    Нет, думать нужно прежде чем пушиться. А со своими локальными правками, которых еще никто не видел, я буду делать все, что захочу.

    > через пару часов использования git сломал нафиг и локальный
    Подскажи рецепт, любопытно.

    > Мучался с ребятами 2 недели
    Работать полноценно я начал сразу, а вот выработать стратегию командной разработки, мерджа веток. Мы еще тогда начали работать через систему форков и пул-реквестов на гитхабе. Вот пока разобрались со всем и отказались от такого подхода и прошло это время.

    > которую не пинал только ленивый
    И буду пинать — до черта людей дальше SVN не видят.

    > где-то месяца 4 воевал с git
    А я не воевал, а радовался во всю. В чем подвох?

    > Git — далеко не лучший представитель этого семейства
    А почему бы не написать свой обзор? Я бы почитал с удовольствием.
  • Почему Git
    0
    Про ограничение доступа:
    Почитайте эту статью: habrahabr.ru/blogs/Git/75990/
    Там автор использует 2 репозитария: 1 — PROD-репо, с ограниченным доступом и второй — песочница для разработчиков.

    > Работа над несколькими проектами с общими компонентами
    см. git help submodule
    В проект можно подключить другие репозитарии как субмодули. Т.е. каждый компонент выделяете в отдельный репозитарий, и подключаете в любых проектах.
  • Почему Git
    0
    Спасибо, добавил в список.
  • Почему Git
    +9
    > Напрямую p2p два клиента без поднимания костылей подключиться и сделать push не могут
    Могут напрямую через ssh
  • Почему Git
    0
    > И ничуть не страдаю от того, что приходится написать git gui и дотянуться до мыши.
    Не ленитесь учиться. Я себя очень часто заставляю залезать в хелп или гуглить, чтобы понять как что-то работает.
  • Почему Git
    0
    Черт, промахнулся. Ответил ниже.
  • Почему Git
    0
    > какой командой надо помечать файлы в которых я разрешил конфликты
    git add path/to/file
  • Symfony Code'n'Coffe (Июль) Москва
    0
    Видео не планировали, да и вообще не планировали записывать. Но я смотрю ребята интересуются, поэтому подумаю о том, что и как можно будет записать.
  • Symfony Code'n'Coffe (Июль) Москва
    0
    Я принципиально выбрал выходные, потому что по будням большинству будет неудобно.
    Не получается сейчас, можно придти в следующий раз.
  • Symfony Code'n'Coffe (Июль) Москва
    0
    Пока далеко для этого, если вообще будем.
    Я планирую регулярно проводить встречи, поэтому всегда будет возможности придти.
  • Doctrine: Опыт работы с миграциями в symfony
    +1
    Лучшее — враг хорошего. Это как раз такой случай.
    Лучше оставить систему очень простой и дописать соглашение, чем неоправданно усложнять и возможно получить новые грабли.
  • Doctrine: Опыт работы с миграциями в symfony
    0
    Теоретически можно, если еще опустить вопросы очередности выполения, и сложных/множества запросов для data migration. А как тогда быть с номером версии БД. Может получится так, что написали одну миграцию, а номер скакнул на 10. А не скакать нельзя — это ролбек. Да и с ролбеком будут проблемы.
    Нет, плохая идея.
    Это на совести разработчика и мануала с best practice
  • Doctrine: Опыт работы с миграциями в symfony
    +1
    Технически — легко.
  • Doctrine: Опыт работы с миграциями в symfony
    +2
    Это уже недостатки текущей реализации. Единственную сложность, которую я вижу, это невозможность автоматом откатить сложную миграцию, если она упала.
    А ваш товарищ, наверное, пришет атомарные миграции.
    Все остальное есть куда допиливать, если еще не допилили во второй доктрине.
  • Doctrine: Опыт работы с миграциями в symfony
    +1
    Ну и здесь используются без проблем. В чем суть спора?
  • Doctrine: Опыт работы с миграциями в symfony
    +1
    см. symfony doctrine:generate-migrations-diff

    > Ей Богу, проще ручками в базе поправить, полученный SQL-код записать в отдельный sql-файл и, при случае, использовать. Меньше проблем, меньше времени, ничего не надо изучать.

    Я про то и писал, что на определенном уровне разработке это намного сложнее, чем использовать миграции.
  • Doctrine: Опыт работы с миграциями в symfony
    0
    Нет. Я не уверен, надо посмотреть исходники, но доктрина оборачивает миграцию в транзакцию и это не спасает. Еще я не знаю дружат ли ALTER и CREATE TABLE с транзакциями. Надо порыться в доке к БД. Или может кто подскажет?