Договоров со спонсорами не заключили видимо тоже в рамках налоговой оптимизации…
> Интересно узнать имя главного спонсора, который половину фонда зажал. (5 страниц на ЛОРе читать влом)
Судя по ЛОРу PingWin Software перечислил 300 т.р. ещё в прошлом году.
А остальные 3 спонсора указаны на странице конкурса: Intel, IBM developerWorks и ГНУ/Линуксцентр.
Интрига видимо в том, что один из спонсоров перечислил организатору 300 т.р., а общий призовой фонд — 500 т.р… При этом организатор пишет, что «недобрали более половины призового фонда».
Вопрос: кто из них лукавит и куда уйдут деньги из призового фонда, если организаторам не удастся найти новых спонсоров для давно прошедшего конкурса?
Выше уже написали, что изготовить пару таких 2D-очков можно из пары обычных стерео-очков просто переставив светофильтры таким образом, чтобы они были одноцветными в итоговых «очках».
В данном случае это даже не очки, а тупо 2 разных светофильтра на картонке, а «очки» из топика — это похоже два одинаковых светофильтра на картонке.
Т.о. если в обычных стерео-очках закрыть один глаз, то получится примерно тоже самое, но если смотреть одним глазом без светофильтров, то будут видны оба изображения.
В дополнение к этому можно вспомнить, что «предварительная оптимизация — зло», и весь этот дополнительный рефакторинг никому не нужен — кодом-то и пользоваться не будут. Посему, в глазах программиста-практика, коим зачастую является преподаватель, такой труд тоже не очень-то обоснован.
Так и есть, только Вы слово оптимизация применили абсолютно не к месту, при проведении рефаторинга в стиле «а вдруг когда-нибудь пригодится» речь идёт о нарушении принципа 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».
> Интересно узнать имя главного спонсора, который половину фонда зажал. (5 страниц на ЛОРе читать влом)
Судя по ЛОРу PingWin Software перечислил 300 т.р. ещё в прошлом году.
А остальные 3 спонсора указаны на странице конкурса: Intel, IBM developerWorks и ГНУ/Линуксцентр.
Вопрос: кто из них лукавит и куда уйдут деньги из призового фонда, если организаторам не удастся найти новых спонсоров для давно прошедшего конкурса?
В данном случае это даже не очки, а тупо 2 разных светофильтра на картонке, а «очки» из топика — это похоже два одинаковых светофильтра на картонке.
Т.о. если в обычных стерео-очках закрыть один глаз, то получится примерно тоже самое, но если смотреть одним глазом без светофильтров, то будут видны оба изображения.
В корректном решении обязательно должна быть проверка на кол-во (не более двух) и тип (только целые числа) полученных от пользователя значений.
Ну и в чём сакральный смысл этой путаницы? Понтануться как круто Вы знаете справочник по 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».