Почему нет? Главное чтоб down корректно обратно все возвращал. И откуда это все "миграции нужны для управления СТРУКТУРОЙ базы данных"? Миграции для изменения структуры данных, да. Но, во первых - данные - это не только база данных. Да, в класс миграции встроенны плюшки для работы с БД - оно и понятно - 90% изменений структуры данных - это бд. Но картинки загруженные пользователями - это не данные?
Про "структуру" я б тоже подискуссировал: разве не бывает такого что при изменении структуры данные не меняются? Вот простой пример - есть у вас 2 поля - дата и время. Вы решили их объединить в DATETIME, ну и соответсвенно, в новое поля записать старые данные (к дате прибавить время) И что, вы действительно будете делать миграцию только на изменение структуры? Если мы сделаем миграцию типа "создать новое, удалить старое" - просрем данные. По вашему получается что нужно сделать две миграции и одну консольную команду: миграция "добавить новое поле", команда "заполнить новое поля данными из старых", миграция "удалить новое поле". Вы действительно так делаете? Реально?
И при применении миграции вы смотрите список невыполненных, думаете, ага, сейчас я мне нужно сделать первые три миграции, потом Колян говорил что там какую-то комманду надо выполнить? Как ее название? сommand_after_commit_0234234? Вроде да? Потом еще 2, потом комманда от Макса... Вы действительно так работаете?
И интересно, как вы оповещаете других 10и разрабов о том что надо выполнить какие-то команды?
Давайте на чистоту: никто так не делает. Все следалют это все в одной миграции, которая содержит не только изменение структуры, но и модификацию данных, возможно, и вставку новых.
Кстати, как мы помним, на изменение структуры транзакции не работает . Но миграциях есть safeUp safeDown - обертка транзакциями, специально для манипуляции с данными. Видимо разработчики yii не знали что миграции чисто для структуры, иначе б удалили эти ненужные методы.
И это ведь еще не самый большой проект, на предыдущей работе было 300 таблиц (правда не изначально) + 40 коллекций в монго и гигабайт начальных данных.
Никита: Обоснуйте. Человеку надо инициалищировать БД. Простой пример - проект в котором я работаю: сейчас ~150 таблиц + ~700 миграций, изначально было ~100 таблиц + сотня тысяч строк статичных данных. В чем преимущество оформлять всю это инициализацию с помощью миграций (опуская мнимое "всегда можем перейти на другую БД")? Сколько недель человек потратит чтобы написать все эти миграции? Сколько ошибок он сделает при этом (в отличии от создания DDL в GUI и дампе этого всего)? Насколько медленнее все это будет выполнятся, например, при поднятии машины с нуля для запуска тестов или еще чего?
Миграции - да, очень крутая штука, но как бы само название говорит что они для мигрирования. Использование их для инициализации - имхо, бессмысленно.
Дмитрий Конуров: FrameLayout позицианирует детей по середине автоматом. Один ребенок - UI для выбора картинки (на весь экран c match_parent) другой - прогресс-бар c wrap_content
Да я ваще хз как народ задания проверяет. Мне как то отказали с формулировкой "ваш код выводит слишком много логов". Ну как бы да, но это отключить - 2 минуты. Иногда подумаешь "это же все-го лишь тестовое задание, срежу угол", как например в этом коде зашиты параметры идентификации. А проверяльшик - вы мудак, так делать нельзя, и все тут. Иногда человек просто более низкой квалификации, и скажет "слишком сложно сделанно" когда у вас все по паттернам разбито, все по науке. Вот в этом коде меня смутил DetailsTaskFragment - но я понимаю что человек просто выбрал эту реализацию, было бы в задании уточнение, возможно, сделал бы по другому, возможно увидев ваш проект следовал бы вашему стилю, это ж не значит что не умеет программировать.
Короче, я в тестовых заданиях разачаровался, зарекся больше их не делать (ну или краткое какое-нить, часа на 2 не более).
1. В самом фреймворке с этим есть определенные проблемы, иногда они доставляют небольшие неудобства (на пример при тестировании) но я не считаю их каким-либо значимымы. Что касается своего кода, то имплементация SOLID лежит чисто на твоей совести. Если ты не умеешь разбивать на классы, паттерны, или делить интерфейсы, то и не будешь, фреймворк тут не при чем. Можете скинуть ссылку на доки ларавела в каком месте он заставляет разработчика в своем коде следовать SOLID, не в части фреймворка, а в части бизнес логики. Просто интересно.
2. middlware vs behaviors - имхо, глупо их сравнивать, потому-что middlware - частное решение, behaviors - общее решение, просто в yii функционал middlware реализован через поведение. Но сам по себе механизм поведений довольно мощьный и позваляет крайне легко делать разные крутые штуки.
3. Это да, с этим согласен, из коробки не так много получаешь, но сообществом/разработчиками написано уже много всего, все спокойно подтягивается через композер, в этом проблем вообще не вижу. Да и есть ли смысл включать все это в фреймворк? Вот например у нас воркеры очередей сделанны на c++ и java. Сможет ли решение от Laravel работать с ними? А если нет - зачем оно мне в фреймворке? Ну и поверьте, Laravel мелочь по сравнению с например Spring Framework.
4. Магии там не так уж и много, имхо. Просто надо знать где она юзается. Хотя вообще магия везде - вы посмотрите на аннотации Simphony - не магия? Препроцессинг\кодогенерация по аннотациям в Java - не магия?
5. То что jQuery вшит в yii2 никоим образом не свидетельствует о том, что у него плохая архитектура. Просто его стандартные скрипты юзают jquery. (или вы считаете что они должны быть сдаланны на чистом JS?) Не нравиться - отключайте, в этом вообще нет проблемы. Я тоже могу сказать что у ларавела плохая архитектура из-за того что он юзает Blade. Согласитесь, глупо звучит. Про консольные приложения - тоже сомнительная предьява. У консольных приложения даже нет возможности рулить ассетами - при чем здесь вообще jQuery?
6. Много раз встречал это утверждение, от разных разработчиков. Но когда видел их код - понимал что они даже не удосужились прочитать документацию. Что что, а вот ActiveRecord в yii - это самый лучший/удобный/крутой ActiveRecord в мире. Просто нужно понимать как его готовить.
7. Документция отстает, это да. Даже больше так: имхо, не хватает примеров лучших практик. Но имхо, ее достаточно, по крайней мере для меня.
В общем, я конечно пишу со своей колокольни, с несколькоими годами разработки на Yii и прекрасным пониманием как он работает внутри, но в общем как то так.
TAnonim: Сам с Symphony не работал (только документацию читал), но это что то типа Энтерпрайз решения для PHP. Порог вхождения выше, но там типа все правильно, все по науке. Хз, имхо, yii - отличный фреймворк. Есть еще Laravel - раньше все пищат что он в разы круче yii, но это справедливо лишь для yii1. Имхо, yii2 как минимум не уступает ему, а местами делает его как щенка )
TAnonim: Это нормальная ситуация. Имхо, в изучении главное поставить и запустить пустое приложение. А потом решать задачу за задачей. Надо загрузить данные по API - читаешь как, делаешь. Надо отобразить форму - читаешь, делаешь. Имхо, делать лучше сразу свой проект, а не абстрактные примеры - мотивации больше.
Я б еще рекомендовал пробежаться по документации. Там ее не так много (по сравнению, например, со spring), она хороша, освещает важные моменты, да и в целом в ней довольно много полезной теоретической инфы. Это для того чтоб понять что вообще фреймворк может, не обязательно вдаваться в подробности реализации. Чтоб потом вы не изобретали велосипедов, которые уже сделанны в фрецмворке.
krawa83: За SortedList спасибо, не знал о таком ) Что касается библиотек - то они по большей части сокращают время. Безусловно, если ты имееш опыт работы с ними. Изучить за 5 часов, безусловно, ничего не успееш.
copal: Имхо, в программировании умение правильно проектировать классы, бизнес логику, знание фремворка и пр. куда важнее математики и алгоритма сортировки пузырком. Но это другая тема...
asmrnv777: Так это вам антивирус говорит? А я думал плей-маркет такое сообщает. Я вот собираюсь встроить в приложение проверку на рутованность телефона (надо проверять что телефон не рутованный, инче запрещать сохранять приватные данные на телефоне). Интересно как антивирусы отреагируют на это...
D' Normalization: Не, на тестовом аккаунте с тестовой картой все работает отлично, определенные проблемы возникали на продакшене и с реальными картами в редких случаях если пользователь ввел неверные данные. Проблема уже решена, просто удивило что банк (проект мой поэтому я и юзал свою карту) не блокирнул меня через некоторое кол-во неуспешных попыток ввести неправильный cvv. Возможно я не попадал под лимиты, ибо вводил попытки были распределены на несколько часов. Возможно банк не счел это брутфорсом, потому что я вводил всего около 10 различных не правильных комбинаций. Возможно не блокирнули потому что я успешно проходил проверку 3D Secure. Но хз, я б на месте банков блокировал спустя 3 проваленных попытки.
