а я в основном чистый SQL использую, когда надо добавить колонку с «not null» констрейнтом и дефолтное значение записать, т.е. логика такая:
1. создать колонку
2. SQL для заполнения значений в ней
3. добавить «not null» constraint
Так Вы говорите не про миграции данных, а про изменение структуры. Текущая структура хорошо читается из ассоциаций в моделях, а манипуляции с данными — это наоборот лишний шум, который мешает понять структуру.
Кстати, я везде пользуюсь джемом annotate_models, чтобы прямо из модели видеть структуру соответствующей таблицы.
Кстати, еще один подход, который я иногда практикую, когда изменение данных очень простое — это в обычной рельсовой миграции просто написать чистый SQL. Переделанный пример из Вашей статьи:
class AddLastSmiledAtColumnToUsers < ActiveRecord::Migration[5.1]
def up
add_column :users, :last_smiled_at, :datetime
add_index :users, :last_smiled_at
connection.execute <<~SQL
update users u
set u.last_smiled_at =
(select max(s.created_at) from smiles s where s.user_id = u.id)
SQL
end
def down
remove_index :users, column: :last_smiled_at
remove_column :users, :last_smiled_at
end
end
Главное преимущество в том, что это никогда ничего не сломает, потому что SQL работает напрямую со структурой базы, которая была создана предыдущими миграциями, и это не зависит от Ruby-кода (когда классы меняются и пр.)
UPD: пардон, этот подход в статье есть, я был невнимателен :)
Я считаю, что миграциям данных вообще не место в кодовой базе, это разовые операции. Лично я просто готовлю скрипты для миграции, которые запускаю после деплоя, но не коммичу их в код, а просто храню в тикете.
Написано сумбурно и без какой-либо внятной структуры. Какая основная идея этого эссе? Обсцессивное стремление автора к контролю и фрустрация от невозможности его всем навязать?
Тоже недавно это видео смотрел. С этим ничто не сравнится :)
В посте видео скучные, просто на одном месте по факту гоняют, а тут прям драйв в реальном окружении с кучей препятствий. Пилот очень крут!
Слышали про гипотезу эффективного рынка? Если вся информация об активе доступна рынку, то цена уже включает эту информацию, и соответственно цена является «честной». Да, крупные новости влияют на цену, но она очень быстро корректируется.
Кстати, во фьючерсах всегда есть доля неопределенности из-за природы контракта (поставка в будущем). Если хотите, можете рыночной ценой считать spot price (цена на данный момент).
Поддерживаю вопрос о примерах. Они были бы полезны, чтобы оценить важность затрат на улучшение эмпатии на сайте в денежном эквиваленте. Например, если это увеличивает доход только на 0.5%, то имеет ли смысл заморачиваться с этим.
Статья несомненно поднимает важный вопрос, об эмпатии несомненно стоит задуматься, но немного статистики существенно бы дополнило картину, учитывая, что написано про «результаты бизнеса» :)
Где обсуждаются деньги, там числовая информация никогда не бывает лишней.
Аналогично, пользуюсь Модульбанком. Только я еще и бухгалтерией их пользуюсь. Очень дешево кстати, всего 5тыс. р. в год. Присылаю им инвойсы, которые я клиенту выставляю, потом одной кнопкой подписываю в личном кабинете все справки о валютных операциях, и еще раз в квартал подписываю перевод в налоговую — на этом вся бухгалтерия с моей стороны заканчивается.
Сорри за некропостинг, а есть ли возможность перезалить картинки, они не отображаются… Я иногда показываю эту статью знакомым, чтобы познакомить их с понятием кардинга :)
зачем же так негативно? Как по мне, парки из таких деревьев намного лучше кладбищ. Здесь же не обязательно дерево в квартире держать. Подросло немного — и можно высадить в парк. Все эмоции — они в голове. Можно же не горевать о потере, а просто быть благодарным, за то, что было хорошо.
В текущей ситуации IPO маловероятно. Им придется раскрыть все финансовые данные, а им этого очень не хочется, по всей видимости. Учитывая еще и мнение общественности о стартапе, IPO будет провальным — акции могут вообще торговаться около нуля.
как по мне, топовых девелоперов (эти их 3%) любая адекватная компания на удаленку и так возьмет. Это про долгосрочные проекты. А на краткосрочные задачи топовые девелоперы вряд ли пойдут, ибо там как правило ничего интересного нет.
Вот я вообще не понимаю, почему разработчики к ним должны идти.
1. создать колонку
2. SQL для заполнения значений в ней
3. добавить «not null» constraint
Кстати, я везде пользуюсь джемом annotate_models, чтобы прямо из модели видеть структуру соответствующей таблицы.
Главное преимущество в том, что это никогда ничего не сломает, потому что SQL работает напрямую со структурой базы, которая была создана предыдущими миграциями, и это не зависит от Ruby-кода (когда классы меняются и пр.)
UPD: пардон, этот подход в статье есть, я был невнимателен :)
В посте видео скучные, просто на одном месте по факту гоняют, а тут прям драйв в реальном окружении с кучей препятствий. Пилот очень крут!
Кстати, во фьючерсах всегда есть доля неопределенности из-за природы контракта (поставка в будущем). Если хотите, можете рыночной ценой считать spot price (цена на данный момент).
Статья несомненно поднимает важный вопрос, об эмпатии несомненно стоит задуматься, но немного статистики существенно бы дополнило картину, учитывая, что написано про «результаты бизнеса» :)
Где обсуждаются деньги, там числовая информация никогда не бывает лишней.
USD
Покупка 64,40
Продажа 65,40
ЦБ 64,99
Евро
Покупка 71,90
Продажа 72,90 (Тут непонятное что-то, баг может быть, не обновились котировки)
ЦБ 73,02
Юань
Покупка 9,10
Продажа 10,50
ЦБ 9,74
В общем, спрэд — 1 рубль. Для сравнения, по доллару у Сбербанка спрэд — 3.1 руб:
Покупка 63,64
Продажа 66,76
Вот я вообще не понимаю, почему разработчики к ним должны идти.