Проблема в том, что в этих csv/xml-файлах хранятся совершенно разные данные, общее для всех только название товара и цена, все остальные поля зависят от конкретного прайса.
Под конкретного заказчика — нет проблем, а что-то универсальное делать — времени нет. Если у Вас есть достаточно свободного времени для создания универсального решения для импорта произвольного набора данных и желание его реализовать, то я только за. Можно обсудить в личке.
Спасибо за замечания. По первым трём пунктам всё понятно, исправлю к следующей минорной версии.
По п.4., насколько я понял, меняется размер вложенного textarea, а не YUIRichEditor.
По п.5. действительно странное поведение под Chrome, выпадающие меню визуального редактора в принципе видны, но они как раз и дают вертикальный скролл.
П.6. похоже тоже имеет смысл, надо подумать…
Из условия задачи: «Количество чисел меньше 10000». Я конечно понимаю, что на современных мощностях преобразовать строку, размером порядка 25 кб, в массив — это фигня. Но в рамках спортивного программирования так не делается. Уж слишком бросается в глаза неоптимальность использования массива для решения данной задачи.
А если уж гнаться за минимальностью кода, то можно ж ещё на 7 символов сократить:
p gets.split.map(&:to_i).max
Ну это в рамках исправления неправильного использования inject…
А вообще все подобные решения неправильны, где запросы типа «Введите первое число: », «Введите второе число: »? Валидация входных данных напрочь отсутствует. А решения с inject вообще решают какую-то другую задачу, ведь они легко могут просуммировать и больше, чем 2 числа.
Я, наверно, вас сильно удивлю, но бывают случаи когда от хранимых процедур никуда не денешься и это реальная необходимость для Rails-проекта.
Что касается, обеспечения ссылочной целостности, то это задача СУБД и лучше уж реализовать её и в ключах и в моделях, чем только в моделях и потом получать пачками «NoMethodError: undefined method `xxx' for nil:NilClass».
Меня попросили показать, как и что умеет ActiveRecord в рельсах, я показал.
Мне показалось, что там было всего пару слов про ActiveRecord, всё остальное — про генераторы кода, миграции и прочие приятности, не имеющие ни малейшего отношения к ORM.
Про 20 лет — просто наблюдение человека, смотрящего со стороны. Такое все жалкое, недоделанное (Entity Framework, Fluent) и тд.
Почитайте Фаулера «Patterns of Enterprise Application Architecture», Active Record ничуть не современнее, чем Data Mapper. Если вы не понимаете смысла незнакомого паттерна, это ещё не значит, что его реализация «жалкая и недоделанная», просто паттерн призван решать задачу по другому и ожидать что NHibernate, реализующий Data Mapper, когда-либо станет похож на Active Record из Rails (а видимо именно по мере похожести определяется доделанность в вашем случае) по меньшей мере очень странно.
Руби озадачивает скоростью, этого достаточно, чтобы во многих нишах о нем даже не вспоминать.
Ну причём тут скорость, мы тут что вообще обсуждаем архитектурные решения или синтетические тесты, результаты которых ничего не значат в реальном мире.
И да, я не видел ни одного крупного проекта, написанного на руби/рельсах с помощью DataMapper'a вместо AR.
А уверен, что видел код всех крупных проектов на руби?
А если серьёзно, существующая для Ruby реализация паттерна Data Mapper, с одноимённым названием, сильно упрощённая и по сути похожа на ActiveRecord под другим углом. О существовании готовых решений уровня Hibernate под Ruby мне не известно.
Спасибо, я знаю про плагин, поэтому и написал «из коробки», вообще логично было бы включить эту функциональность в Rails.
> Но вообще говоря, в рельсах есть штуки, на которые люди, умеющие готовить sql, смотрят с презрением.
Ну такие штуки есть в любом ORM, именно поэтому надо понимать как конкретный ORM работает и какие запросы он генерирует за кадром, иначе такой фигни можно понаписать…
А вообще Active Record в Rails очень прилично реализован, ему бы ещё поддержку DISTINCT получше сделать и вообще шикарно будет :-)
В файле модели user.rb нужно (между class и end) написать has_many :posts, :dependent => :destroy, а у поста — наоборот belongs_to :user.
Теперь если мы удалим юзера, удалятся все его посты (dependent можно не указывать, тогда не удалятся)
Управление ссылочной целостностью данных на уровне приложения — это не та вещь, которой стоит гордиться… А вот задать нормальные foreign keys на уровне БД в Rails, к сожалению, до сих пор довольно сложно, если не использовать raw SQL под конкретную СУБД, особенно «из коробки».
> NHibernate — это ActiveRecord из Rails, сделанный будто бы лет 20 назад.
Это фактическая ошибка. NHibernate реализует сложный набор паттернов: Data Mapper, Identity Map, Unit of Work.
ActiveRecord в свою очередь реализует паттерн Active Record, который является одним из самых простых вариантов реализации ORM, и даже нарушает SRP (принцип единственной ответственности) для сохранения максимальной простоты.
И хоть я сам сейчас программирую преимущественно на Ruby, мне кажется, не очень этично глумиться над людьми, которые в силу специфики своих проектов вынуждены использовать более сложное решение на основе Data Mapper, а не простенькое на основе Active Record.
P.S. На всякий случай упомяну, что паттерн Active Record реализован для всех популярных языков, а не только для Ruby.
Так что принципиальные отличия в паттернах «Data Mapper vs Active Record», а не в Rails. Одно из ключевых отличий состоит в том, что Data Mapper создаёт объекты на основе произвольного набора данных из базы данных, а Active Record на основе одной единственной таблицы в базе данных.
P.P.S. Миграции к ORM вообще никакого отношения не имеют, они относятся к вопросу создания и редактирования схемы базы данных, а не к вопросу преобразования отношений в объекты.
Согласен, inherited_resources — это вещь в стиле «как сделать простые вещи сложными». Если в проекте много однотипных простеньких контроллеров, то в разы лучше будет создать обычный базовый класс контроллера с минимумом магии и метапрограммирования, который идеально подойдёт под потребности конкретного проекта.
А использовать inherited_resources для нетривиальных контроллеров == снижать читабельность кода в разы.
Да всё кроме IxD (проектирования взаимодействия) и миссии сайта — «борьба с симптомами».
На SEO пользователям глубоко наплевать, а когда эта оптимизация агрессивна, то она идёт только во вред пользователям.
«приятный дизайн» — это субъективизм.
«правильная типографика» в вебе — это только для особо эстетствующих маргиналов, большинству пользователей плевать на типографику, а от выносок многих вообще подташнивает.
«удобная навигация» — это верхушка айсберга IxD, скажу только что одной только «удобной» мало.
Да какой эффект не используй, получить больше энергии, чем пользователь затратил на нажимание кнопки, невозможно.
Вы физику только в школе проходили что-ли? В природе есть масса источников энергии, помимо механической.
Дело в том, что Вы вообще неправильно считаете, не важно какую работу Вы совершили, важно какое напряжение в итоге этой работы можно получить на вход дальнейшей схемы преобразователя питания. Вот тут и вступают в действие немеханические эффекты.
К примеру, Вы хотя бы бытовую пьезозажигалку когда-нибудь видели? Она выдаёт искру, пробивающую воздушный зазор, шириной примерно 3 мм. Т.е. выдаёт напряжение не менее 3 кВ. При этом усилие нажатия клавиши примерно 20-30 H, а ход клавиши до получения первой искры не более 5 мм. Т.е. если взять такой же самый дешёвый пьезоэлемент и посчитать для него выдаваемое электрическое напряжение при 1 Н и 5 мм, то получается не менее 100 Вольт. Так что «если непрерывно стучать со скоростью 200 нажатий/минуту», то можно вполне неплохой источник питания замутить.
Сильно востребованные возможности попадут в Roadmap на следующие релизы.
Под конкретного заказчика — нет проблем, а что-то универсальное делать — времени нет. Если у Вас есть достаточно свободного времени для создания универсального решения для импорта произвольного набора данных и желание его реализовать, то я только за. Можно обсудить в личке.
Мда, видимо Яндекс в очередной раз поменял формат выдачи… Чувствую придётся эту возможность выносить в отдельное расширение.
> «Поддержка юр.лиц» — можно поподробнее, какие у вас планы?
В первую очередь возможность выставления счёта для своей организации после оформления заказа.
> Планируется ли пакетная загрузка товаров, прайс-листов?
Пока она делается только под заказ, какой-то универсальный механизм под любой формат прайс-листов в ближайшее время не планируется.
По п.4., насколько я понял, меняется размер вложенного textarea, а не YUIRichEditor.
По п.5. действительно странное поведение под Chrome, выпадающие меню визуального редактора в принципе видны, но они как раз и дают вертикальный скролл.
П.6. похоже тоже имеет смысл, надо подумать…
А если уж гнаться за минимальностью кода, то можно ж ещё на 7 символов сократить:
p gets.split.map(&:to_i).max
puts gets.split.inject(0) { |memo, num| num.to_i + memo }
Ну это в рамках исправления неправильного использования inject…
А вообще все подобные решения неправильны, где запросы типа «Введите первое число: », «Введите второе число: »? Валидация входных данных напрочь отсутствует. А решения с inject вообще решают какую-то другую задачу, ведь они легко могут просуммировать и больше, чем 2 числа.
Что касается, обеспечения ссылочной целостности, то это задача СУБД и лучше уж реализовать её и в ключах и в моделях, чем только в моделях и потом получать пачками «NoMethodError: undefined method `xxx' for nil:NilClass».
Почитайте Фаулера «Patterns of Enterprise Application Architecture», Active Record ничуть не современнее, чем Data Mapper. Если вы не понимаете смысла незнакомого паттерна, это ещё не значит, что его реализация «жалкая и недоделанная», просто паттерн призван решать задачу по другому и ожидать что NHibernate, реализующий Data Mapper, когда-либо станет похож на Active Record из Rails (а видимо именно по мере похожести определяется доделанность в вашем случае) по меньшей мере очень странно.
Ну причём тут скорость, мы тут что вообще обсуждаем архитектурные решения или синтетические тесты, результаты которых ничего не значат в реальном мире.
А уверен, что видел код всех крупных проектов на руби?
А если серьёзно, существующая для Ruby реализация паттерна Data Mapper, с одноимённым названием, сильно упрощённая и по сути похожа на ActiveRecord под другим углом. О существовании готовых решений уровня Hibernate под Ruby мне не известно.
> Но вообще говоря, в рельсах есть штуки, на которые люди, умеющие готовить sql, смотрят с презрением.
Ну такие штуки есть в любом ORM, именно поэтому надо понимать как конкретный ORM работает и какие запросы он генерирует за кадром, иначе такой фигни можно понаписать…
А вообще Active Record в Rails очень прилично реализован, ему бы ещё поддержку DISTINCT получше сделать и вообще шикарно будет :-)
Управление ссылочной целостностью данных на уровне приложения — это не та вещь, которой стоит гордиться… А вот задать нормальные foreign keys на уровне БД в Rails, к сожалению, до сих пор довольно сложно, если не использовать raw SQL под конкретную СУБД, особенно «из коробки».
Это фактическая ошибка. NHibernate реализует сложный набор паттернов: Data Mapper, Identity Map, Unit of Work.
ActiveRecord в свою очередь реализует паттерн Active Record, который является одним из самых простых вариантов реализации ORM, и даже нарушает SRP (принцип единственной ответственности) для сохранения максимальной простоты.
И хоть я сам сейчас программирую преимущественно на Ruby, мне кажется, не очень этично глумиться над людьми, которые в силу специфики своих проектов вынуждены использовать более сложное решение на основе Data Mapper, а не простенькое на основе Active Record.
P.S. На всякий случай упомяну, что паттерн Active Record реализован для всех популярных языков, а не только для Ruby.
Так что принципиальные отличия в паттернах «Data Mapper vs Active Record», а не в Rails. Одно из ключевых отличий состоит в том, что Data Mapper создаёт объекты на основе произвольного набора данных из базы данных, а Active Record на основе одной единственной таблицы в базе данных.
P.P.S. Миграции к ORM вообще никакого отношения не имеют, они относятся к вопросу создания и редактирования схемы базы данных, а не к вопросу преобразования отношений в объекты.
А по поводу даблклика на вкладке, я тоже не понял в каких ситуациях это может быть удобно для обновления страницы…
А использовать inherited_resources для нетривиальных контроллеров == снижать читабельность кода в разы.
На SEO пользователям глубоко наплевать, а когда эта оптимизация агрессивна, то она идёт только во вред пользователям.
«приятный дизайн» — это субъективизм.
«правильная типографика» в вебе — это только для особо эстетствующих маргиналов, большинству пользователей плевать на типографику, а от выносок многих вообще подташнивает.
«удобная навигация» — это верхушка айсберга IxD, скажу только что одной только «удобной» мало.
Дело в том, что Вы вообще неправильно считаете, не важно какую работу Вы совершили, важно какое напряжение в итоге этой работы можно получить на вход дальнейшей схемы преобразователя питания. Вот тут и вступают в действие немеханические эффекты.
К примеру, Вы хотя бы бытовую пьезозажигалку когда-нибудь видели? Она выдаёт искру, пробивающую воздушный зазор, шириной примерно 3 мм. Т.е. выдаёт напряжение не менее 3 кВ. При этом усилие нажатия клавиши примерно 20-30 H, а ход клавиши до получения первой искры не более 5 мм. Т.е. если взять такой же самый дешёвый пьезоэлемент и посчитать для него выдаваемое электрическое напряжение при 1 Н и 5 мм, то получается не менее 100 Вольт. Так что «если непрерывно стучать со скоростью 200 нажатий/минуту», то можно вполне неплохой источник питания замутить.