В дополнение к этому можно вспомнить, что «предварительная оптимизация — зло», и весь этот дополнительный рефакторинг никому не нужен — кодом-то и пользоваться не будут. Посему, в глазах программиста-практика, коим зачастую является преподаватель, такой труд тоже не очень-то обоснован.
Так и есть, только Вы слово оптимизация применили абсолютно не к месту, при проведении рефаторинга в стиле «а вдруг когда-нибудь пригодится» речь идёт о нарушении принципа YAGNI. Гораздо лучше будет, если синтетическая задача будет реально располагать к рефакторингу, так польза от него запомнится лучше, чем в случае вымученного и неуместного рефакторинга ради галочки.
Если Вы забыли, повторюсь, что решение с использованием inject для данной задачи является абсолютно неверным.
В корректном решении обязательно должна быть проверка на кол-во (не более двух) и тип (только целые числа) полученных от пользователя значений.
так тут речь даже не про хостинг, а про домены, которые даже в зоне .ru в некоторых местах за 100 р. в год можно купить… не говоря о куче бесплатных доменов третьего уровня.
> аккумулятор в моём примере строка только на первой итерации.
Ну и в чём сакральный смысл этой путаницы? Понтануться как круто Вы знаете справочник по Ruby? Даже если я его перечитаю, я всё равно буду утверждать, что это пример крайне плохого, нечитабельного кода с лишними приведениями типов, т.к. даже Integer#to_i вызывать глупо. Так программировать не надо, а учить других так программировать вообще злодеяние.
Зависит от специфики магазина. При необходимости для конкретного магазина всегда можно добавить ссылку «Продолжить покупки» или сделать добавление товаров в корзину при помощи AJAX. Я не считаю, что этот аспект принципиален для демо-магазина.
Причём тут Integer#to_i? Ваш вариант эквивалентен вызову:
puts gets.split.inject("") { |memo, num| num.to_i + memo.to_i }
Это в принципе работает, но складывать числа, помещая промежуточные результаты в строку, — это явно плохой пример новичкам. Да и вообще абсурдно как-то, не?
Если сомневаетесь, что аккумулятор в вашем примере строка, можете попробовать:
puts gets.split.inject { |memo, num| num.to_i + memo }
Проблема в том, что в этих 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 под конкретную СУБД, особенно «из коробки».
В корректном решении обязательно должна быть проверка на кол-во (не более двух) и тип (только целые числа) полученных от пользователя значений.
Ну и в чём сакральный смысл этой путаницы? Понтануться как круто Вы знаете справочник по Ruby? Даже если я его перечитаю, я всё равно буду утверждать, что это пример крайне плохого, нечитабельного кода с лишними приведениями типов, т.к. даже Integer#to_i вызывать глупо. Так программировать не надо, а учить других так программировать вообще злодеяние.
Мануал: spreecommerce.com/documentation/customization.html
Идёт работа над дальнейшем упрощением внесения изменений в шаблоны. В 0.70 для этого будет задействован Deface
puts gets.split.inject("") { |memo, num| num.to_i + memo.to_i }
Это в принципе работает, но складывать числа, помещая промежуточные результаты в строку, — это явно плохой пример новичкам. Да и вообще абсурдно как-то, не?
Если сомневаетесь, что аккумулятор в вашем примере строка, можете попробовать:
puts gets.split.inject { |memo, num| num.to_i + memo }
Сильно востребованные возможности попадут в 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 под конкретную СУБД, особенно «из коробки».