Я понял, в чём идея миграций, и согласен что это вещь нужная и удобная. Главное, чтобы разработчик не поленился, и создал миграцию для своих изменений.
В комментарии, видимо я неправильно сформулировал мысль: хотелось бы иметь решение, которое проверяет, две БД, и различия в них выводит в соответствующий SQL-код (миграцию и откат, соответственно два файла). Как-то так.
Например:
Разработчик закончил пились свою фичу, отполировал код, и надо ему написать миграцию для БД. Он запускает скрипт, где указывает целевую БД и свою БД как источник. Скрипт сравнивает базы и генерирует два SQL-файла: миграцию и откат (что по сути является обратной миграцией с целевой БД на БД разработчика).
Остаётся только заполнить соответствующие файлы/методы/функции в коде миграции — и вуаля. :)
Я представлял себе решение, которое сравнивает production и development БД, и создаёт, полностью самостоятельно, соответствующие миграции (SQL-файлы) с данными.
В вашем случае — разработчику также достаётся ручное отслеживание, что именно изменилось и какие изменения нужно внести в production БД. Согласен, что это намного удобнее, чем ручной цикл (особенно в плане «версионного контроля» БД), но для полной автоматизации процесса ещё есть место. :)
Из замечаний:
— чат не переносит строки, которые больше ширины окна чата;
— а можно туториал (да и наверное системные сообщения) складывать в историю «системного чата»? Был момент, когда я прошляпил, что написали в туториале, а опять посмотреть негде. Или может есть где, но не нашёл :)
— Торговля: в магазинах (те что на планетах) не понял: где всё же цена? Или там отдельно цена продажи-покупки? Если да, то неочевидно, куда смотреть.
Ну в остальном из замеченного, как я понял — недоделанные моменты присутствуют.
Игра получается очень даже неплохой. Автор просто поразил меня: в одиночку пилить такое! Это железная воля и целеустремлённость какая должна быть. Респект!
Например, частый случай для нас: мы написали часть приложения, клиент посмотрел его и понял, что ему надо не это. Он даже не спорит, что надо доплатить за переделку, но просит сделать по-быстрее, т.к. у него уже есть бизнес план и т.д.
Если у вас работа идёт в таком ключе, то возможно, что тесты действительно никак не помогут.
Если у вас «ядро» системы не меняется никогда, а вся работа идёт только на уровне бизнес-логики, которая вполне может сразу после написания отправится в корзину — да, вероятно вам тесты не нужны. :)
Но если вы можете выделить код, который живёт достаточно долго, с которым вы регулярно работаете, и в котором в ходе жизненного цикла происходят изменения — тесты могут весьма облегчить задачу. А если вы работаете над «продуктом» как единицей программного обеспечения, то тут они будут весьма и весьма полезны.
Я имел ввиду, что если ошибка была в том, что мы скачиваем изображение, его расширение jpeg, мы считаем, что это jpeg, а оно bmp внутри. То для этого случая можно написать тест. Но зачем, если в функции мы уже всё равно проверяем по содержимому?
Ну как «зачем»? Чтобы проверить в интерфейсе пользователя, который загружает изображение, что всё работает как надо.
Если при загрузке bmp вместо jpg у вас должно показываться предупреждение пользователю: пишем функциональный тест, который это проверяет.
А то, что у вас сейчас проверяется внутри функции — это можно протестировать уже юнит-тестами.
В своё время я долго не мог въехать в принципиальную разницу: юнит-тесты — это тесты разработчиков. Эти тесты подтверждают: поведение кода не изменилось, все тестируемые функции-методы работают именно так, как и работали (это утверждение может быть неверным, если при написании теста вы прошляпили что-нибудь. К примеру — не добавили проверку деления на ноль в методе divide(a, b) ).
Сам факт: собрался рефакторить метод — разберись, что делает метод, напиши тесты на его поведение перед изменением и убедись что они все зелёные.
Теперь можно рефакторить, и после изменения метода не придётся лезть в браузер и проводить функциональное тестирование, чтобы убедится что этот один изменённый метод работает как прежде. Нужно будет просто запустить после рефакторинга (и/или в процессе рефакторинга) тесты и убедится, что после изменения всё работает также. Экономия на времени и телодвижениях.
Функциональное тестирование — это уже проверка того что приложение работает как ожидается. Это проверка поведения в браузере, если вы скармливаете неправильный файл. Проверяете — видит ли пользователь сообщение об ошибке. Это проверка того, что пользователь действительно может залогинится в приложении. Это проверка того, что он может разлогинится.
Почувствуйте разницу:
1. проверка того, что пользователь может зайти на страницу логина, ввести работающие логин и пароль, и после этого он залогинится в систему.
2. проверка того, что если методу Auth::login($user, $pass) отдать работающие логин и пароль, в сессии появятся соответствущие данные.
В принципе это может быть две стороны одной медали, но назначение этих разных видов тестирование несколько отличается.
Опять же — для функционального тестирования тоже есть инструменты, которые позволяют описать последовательность действий и ожидаемый результат. А уже инструменты тестирования сами разберуться с запуском браузера и запрограммированными в тесте действиями.
Опять же — экономия телодвижений и времени.
Но всё это требует «въезжания» в своеобразную философию тестирования. Более продвинутый коллега, которого я в своё время расспрашивал о плюсах и минусах юнит-тестов, сразу предупредил: «В среднем на переосмысление своей методики работы и переход к TDD уходит около года. Большая часть времени уходит на понимание того, что тебе это действительно нужно. И несомненно есть задачи, при которых следование методике TDD не оправдывает себя. Но чтобы это утверждать, ты должен владеть TDD и понимать, в каких случаях тебе это не нужно».
Выравниваю, хоть и без особого фанатизма. Например, нет смысла выравнивать такое:
// some code here
...
$short = 'some value of short variable';
$someLongVariableNameHere = 'value of long variable name';
// and code here
...
Две-три переменные, с настолько разной длиной имён… Ерунда вобщем.
А вот в групповых присвоениях: массивы, группа свойств, блок переменных — тут уже для удобочитаемости выравниваю. Тем самым облегчаю дальнейшее сопровождение кода: читается выровненный блок намного проще.
Очевидно, что это неспроста. Скорее всего, автор чаще говорит на родном языке, чем на русском. ;)
Совершенно не вижу в этом повода минусовать автору карму. А, кстати… А что вы думаете по поводу статьи?
Ситуация с плеерами, это ошибка программистов, которые не стали следовать стандарту до конца, а реализовали только этап воспроизведения нотных данных. Логика, которой они руководствовались, скорее всего проста: обычный пользователь вряд ли будет работать с миди-файлами, содержащими необычные данные. Соответственно — можно сэкономить время.
А вот если использовать для воспроизведения секвенсор (то есть программу, априори предназначенную для работы с миди-протоколом, в числе прочего) то всё нормально. Просто потому, что задача этого ПО несколько другая.
А почему он воспроизводится в QuickTime без ошибок, так на это есть ответ в статье:
Причина тому проста — QuickTime Player использует свой собственный синтезатор (разработанный, однако, Roland)
Всё же Roland — далеко не последнее имя в разработке всяких синтезаторов, работающих в том числе с управлением по миди-протоколу. И было бы просто позорно, если бы у такого производителя, грубо говоря, собственный протокол не работал как следует. :)
Сотрудники Google приводят ещё один интересный факт — растущую популярность двухфакторной аутентификации, когда дополнительно к паролю приходит одноразовый код на телефон.
О, да. Я тоже невольно приложил к этому руку несколько дней назад. Когда просто не смог проверить почту, в обход предложения всё же использовать двухфакторную авторизацию (ну или, возможно, просто не нашёл как проверить в обход этого настойчивого предложения) :)
Хотя, с некоторыми операторами бывает непросто получить код авторизации.
Преподаватель: Так, сейчас вопрос. Ответивший — получает зачёт автоматом. Вопрос несложный. Готовы?
Аудитория: Да-а-а-а!
Преподаватель: Вам нужно проверить наличие тока на этом проводе. Как будете проверять: тыльной стороной ладони или лицевой?
Аудитория: *расслабившись* Ясное дело — ТЫЛЬНОЙ!
Преподаватель: А почему?
Аудитория: *снисходительно* Если под напряжением, то мышцы сократятся. Если лицевой хватать — ладонь сожмётся, и не сможешь выбросить провод. А если тыльной — то рука дёрнется в другую сторону.
Преподаватель: Молодцы, зачёт никто автоматом не получит.
Аудитория: Как так?
Преподаватель: Ребята, вы будущие электрики или кто? Наличие напряжения проверяется вольтметром или индикаторной лампой, а не ладонью.
Очень не хватает?
forum.kohanaframework.org/discussion/5274/a2-kohanas-acl-module/p1
Там вполне удобно можно создать роли и прописать доступ к ресурсам. По сути — это порт Zend ACL модуля для разграничения доступа.
В комментарии, видимо я неправильно сформулировал мысль: хотелось бы иметь решение, которое проверяет, две БД, и различия в них выводит в соответствующий SQL-код (миграцию и откат, соответственно два файла). Как-то так.
Например:
Разработчик закончил пились свою фичу, отполировал код, и надо ему написать миграцию для БД. Он запускает скрипт, где указывает целевую БД и свою БД как источник. Скрипт сравнивает базы и генерирует два SQL-файла: миграцию и откат (что по сути является обратной миграцией с целевой БД на БД разработчика).
Остаётся только заполнить соответствующие файлы/методы/функции в коде миграции — и вуаля. :)
DmitryKoterov, спасибо за ссылку, гляну.
В вашем случае — разработчику также достаётся ручное отслеживание, что именно изменилось и какие изменения нужно внести в production БД. Согласен, что это намного удобнее, чем ручной цикл (особенно в плане «версионного контроля» БД), но для полной автоматизации процесса ещё есть место. :)
Из замечаний:
— чат не переносит строки, которые больше ширины окна чата;
— а можно туториал (да и наверное системные сообщения) складывать в историю «системного чата»? Был момент, когда я прошляпил, что написали в туториале, а опять посмотреть негде. Или может есть где, но не нашёл :)
— Торговля: в магазинах (те что на планетах) не понял: где всё же цена? Или там отдельно цена продажи-покупки? Если да, то неочевидно, куда смотреть.
Ну в остальном из замеченного, как я понял — недоделанные моменты присутствуют.
Игра получается очень даже неплохой. Автор просто поразил меня: в одиночку пилить такое! Это железная воля и целеустремлённость какая должна быть. Респект!
То есть это означает: «А фиг его знает, поменяется спин у второго или нет»?
Если у вас работа идёт в таком ключе, то возможно, что тесты действительно никак не помогут.
Если у вас «ядро» системы не меняется никогда, а вся работа идёт только на уровне бизнес-логики, которая вполне может сразу после написания отправится в корзину — да, вероятно вам тесты не нужны. :)
Но если вы можете выделить код, который живёт достаточно долго, с которым вы регулярно работаете, и в котором в ходе жизненного цикла происходят изменения — тесты могут весьма облегчить задачу. А если вы работаете над «продуктом» как единицей программного обеспечения, то тут они будут весьма и весьма полезны.
Ну как «зачем»? Чтобы проверить в интерфейсе пользователя, который загружает изображение, что всё работает как надо.
Если при загрузке bmp вместо jpg у вас должно показываться предупреждение пользователю: пишем функциональный тест, который это проверяет.
А то, что у вас сейчас проверяется внутри функции — это можно протестировать уже юнит-тестами.
В своё время я долго не мог въехать в принципиальную разницу: юнит-тесты — это тесты разработчиков. Эти тесты подтверждают: поведение кода не изменилось, все тестируемые функции-методы работают именно так, как и работали (это утверждение может быть неверным, если при написании теста вы прошляпили что-нибудь. К примеру — не добавили проверку деления на ноль в методе divide(a, b) ).
Сам факт: собрался рефакторить метод — разберись, что делает метод, напиши тесты на его поведение перед изменением и убедись что они все зелёные.
Теперь можно рефакторить, и после изменения метода не придётся лезть в браузер и проводить функциональное тестирование, чтобы убедится что этот один изменённый метод работает как прежде. Нужно будет просто запустить после рефакторинга (и/или в процессе рефакторинга) тесты и убедится, что после изменения всё работает также. Экономия на времени и телодвижениях.
Функциональное тестирование — это уже проверка того что приложение работает как ожидается. Это проверка поведения в браузере, если вы скармливаете неправильный файл. Проверяете — видит ли пользователь сообщение об ошибке. Это проверка того, что пользователь действительно может залогинится в приложении. Это проверка того, что он может разлогинится.
Почувствуйте разницу:
1. проверка того, что пользователь может зайти на страницу логина, ввести работающие логин и пароль, и после этого он залогинится в систему.
2. проверка того, что если методу Auth::login($user, $pass) отдать работающие логин и пароль, в сессии появятся соответствущие данные.
В принципе это может быть две стороны одной медали, но назначение этих разных видов тестирование несколько отличается.
Опять же — для функционального тестирования тоже есть инструменты, которые позволяют описать последовательность действий и ожидаемый результат. А уже инструменты тестирования сами разберуться с запуском браузера и запрограммированными в тесте действиями.
Опять же — экономия телодвижений и времени.
Но всё это требует «въезжания» в своеобразную философию тестирования. Более продвинутый коллега, которого я в своё время расспрашивал о плюсах и минусах юнит-тестов, сразу предупредил: «В среднем на переосмысление своей методики работы и переход к TDD уходит около года. Большая часть времени уходит на понимание того, что тебе это действительно нужно. И несомненно есть задачи, при которых следование методике TDD не оправдывает себя. Но чтобы это утверждать, ты должен владеть TDD и понимать, в каких случаях тебе это не нужно».
Как-то так. :)
Две-три переменные, с настолько разной длиной имён… Ерунда вобщем.
А вот в групповых присвоениях: массивы, группа свойств, блок переменных — тут уже для удобочитаемости выравниваю. Тем самым облегчаю дальнейшее сопровождение кода: читается выровненный блок намного проще.
Совершенно не вижу в этом повода минусовать автору карму. А, кстати… А что вы думаете по поводу статьи?
В смысле — вам хотелось бы сменить свою связку на PhpStorm, но надо чтобы вас в этом убедили? О_о
И почему не подходил компонент из Symfony?
Эти мелочи могут стать важным звеном при оценке библиотек.
Как-то так :)
А вот если использовать для воспроизведения секвенсор (то есть программу, априори предназначенную для работы с миди-протоколом, в числе прочего) то всё нормально. Просто потому, что задача этого ПО несколько другая.
А почему он воспроизводится в QuickTime без ошибок, так на это есть ответ в статье:
Всё же Roland — далеко не последнее имя в разработке всяких синтезаторов, работающих в том числе с управлением по миди-протоколу. И было бы просто позорно, если бы у такого производителя, грубо говоря, собственный протокол не работал как следует. :)
При сохранении под другим именем в формате MIDI 1 — файл «похудел» на три килобайта. :)
О, да. Я тоже невольно приложил к этому руку несколько дней назад. Когда просто не смог проверить почту, в обход предложения всё же использовать двухфакторную авторизацию (ну или, возможно, просто не нашёл как проверить в обход этого настойчивого предложения) :)
Хотя, с некоторыми операторами бывает непросто получить код авторизации.
Преподаватель: Так, сейчас вопрос. Ответивший — получает зачёт автоматом. Вопрос несложный. Готовы?
Аудитория: Да-а-а-а!
Преподаватель: Вам нужно проверить наличие тока на этом проводе. Как будете проверять: тыльной стороной ладони или лицевой?
Аудитория: *расслабившись* Ясное дело — ТЫЛЬНОЙ!
Преподаватель: А почему?
Аудитория: *снисходительно* Если под напряжением, то мышцы сократятся. Если лицевой хватать — ладонь сожмётся, и не сможешь выбросить провод. А если тыльной — то рука дёрнется в другую сторону.
Преподаватель: Молодцы, зачёт никто автоматом не получит.
Аудитория: Как так?
Преподаватель: Ребята, вы будущие электрики или кто? Наличие напряжения проверяется вольтметром или индикаторной лампой, а не ладонью.
:)
и