Исправление уязвимостей в Ruby on Rails

отсталый глючиный клон админки джанго/flask admin?

хм.. давай проверим в activeadmin модель генерируется так

rails generate active_admin:resource [MyModelName]

Это не одно и тоже, flask - гребанный конструктор, на гребанном питоне, а activeadmin - искоробочное CRUD решение.

Кому вообще интересно чего там тебе не хватает, нет такой шкалы «нехватка по xpahos», можно сравнить только наличие (отсутствие), и чтобы далеко не ходить вот https://www.ruby-toolbox.com/#Active_Record_Plugins найдутся ли аналоги у Pyramid/django, например, для группы Active_Record_Plugins, хотя бы по одному аналогу на каждую подгруппу. Повторюсь, мне не интересно хватает тебе этого, или нет, рассматривается только вопрос присутствия.

Замечательно, а теперь что это такое? :)

Расширения для ORM, у django есть ORM?

Расширения для ORM, у django есть ORM?

Да есть. Весьма убогая, но есть. «Расширения» тоже есть, но говном она от этого не перестает быть.

И в догонку, это не единственная вещь, так же есть http://rails-admin-tb.herokuapp.com/
https://github.com/activescaffold/active_scaffold

Мораль - на джанге одно кривое решение, на рельсах 3 отличных. Django — пациент скорее..? - вот тред стона, где автор не может сделать то, что он хочет («чекбоксам добавить один атрибут»), а вот в rails_admin, он бы точно не имел с этим проблем т.к. вот здесь https://github.com/sferik/rails_admin/blob/master/app/views/rails_admin/main/... просто добавил бы его к field.html_attributes (это специальные сгенерированые views для редактирования). Через 3-5 лет, возможно, на python будет 2-3 хорошие аналогичные системы, и через 3-5 лет автор того треда, возможно, решит свою проблему, но не факт, я склонен давать пессимистичные прогнозы :) Через 3-5 лет оно окончательно сдохнет! рррРР

1) активрекорд это вообще убожество по сравнению с алхимией например

Аналог алхимии - Arel, а не ActiveRecord. ActiveRecord - это более высокоуровневая надстройка над Arel. Кому не хватает AR, но неохота ковыряться в Arel - есть https://github.com/ernie/squeel

Что за 3 способа?

Классы с потомками в одной табличке и есть поле с идентификатором типа (меньше таблиц зато поля есть пустующие).

На каждый класс по табличке вне зависимости от наследования (избыточность).

Общие поля в одной, а поля потомков раскинуты по своим табличкам (все нормализовано нет избыточности, но таблиц еще больше и много «джойнов» в результирующем SQL).

Вообще ява не слишком динамична, боюсь это откладывает серьезный
отпечаток на конструирование моделей, нельзя же там сделать так
https://github.com/brainspec/enumerize, или так http://apidock.com
/rails/ActiveRecord/Base/serialize/class, я конечно понимаю,
что не нужно, но все-же..

Все это есть и язык тут не причем, библиотека старше.

Общие поля в одной, а поля потомков раскинуты по своим табличкам

Это ж просто вариация has_one

На каждый класс по табличке

Ничто не мешает изменить имя таблицы в наследованной модели (хотя я не занимался этим, т.к в ruby имеется возможность перенести общий функционал в отдельный модуль).

язык тут не причем, библиотека старше

http://habrahabr.ru/post/29694/ - да все норм, триллионы бойлерплейта, как всегда.

Кончай перечислять нагромождения никому на практике не нужных конструкций созданных не понятно для чего. Как то уж очень нагло ведут себя рельсисты учитывая 4 темы про безопасность в рейлс на одной странице www.linux.org.ru/news/security/. Должны бы вроде попрятаться от стыда. Ещё какая то дура потёрла мои сообщения с комментарием «Провокация flame». Что за дебилы воспринимают описание очевидных недостатков технологии так болезненно? Тупой форум блин!

нагромождения

Ха) это только парочка, это только раилс, а есть еще огромное количество, следуя твоей логике, абсолютно безбажного софта (ведь сообщений об угрозах на лоре не было))

ололо статья 2008 года)))

хм.. и верно, сейчас все по-другому?)

http://javaxblog.ru/article/java-hibernate-1/

Ну вот и все!

Ахах) В этом всем реально есть такая необходимость..? Просто весь этот путь (от коннекта, до сохранения объектов), на руби займет строчек.. 10.

Ха) это только парочка, это только раилс, а есть еще огромное количество, следуя твоей логике, абсолютно безбажного софта (ведь сообщений об угрозах на лоре не было))

Прошу привести конкретный случай когда в течении полутора месяцев в Pyramid было обнаружено 4 серьёзных бага (серьёзным является баг связанный с безопасностью).

А нагромождения всяческого говна которые вы тут так старательно описываете совершенно не нужны на практике т.к. всё решается другими средствами зачастую более эффективно.

Большинство из вами перечисленного имеет очень низкую стабильность работы (как почти всё написанное на руби). Очевидно для рубиста главное - нагородить херни из сомнительных third-party компонентов особо не задумываясь о безопасности, стабильности, и целостности конечной системы.

Прошу привести конкретный случай когда в течении полутора месяцев в Pyramid

Во первых, это абсолютно не означает, что багов там нет))
Комьюнити у рельс больше в десятки раз => вероятность найти баг больше (что кстати ты и наблюдаешь), соответственно комьюнити шпирамид в десятки раз меньше => вероятность найти баг гораздо меньше.
Кроме того, я уже (как минимум) дважды слышал, о том что в питоновом коде трудно разбираться (и, кстати, ни разу! не слышал такого про руби), т.е. вероятность найти баг в питоновом _коде_ ~= 0, можно найти только проявление бага, а => вероятность существования багов в пирамиде еще больше. Короче, верь мне, они есть, их много, и ты так просто их не найдешь).

Во-вторых, это хрень к рельсам вообще никак не относится.

стабильность работы

Руби программы очень стабильны, это связано с высокой степенью модульности (повторного использования хорошо-оттестированного кода), доступности инструментов разработки, удобным языковым конструкциям и языковой парадигме. Никогда не слышал, чтобы раилз падал.

нормальные библиотеки которые вы тут так старательно описываете совершенно не нужны питонщикам

ну ок.

т.к. всё решается другими средствами

В виду отсутствия - несомненно)) И я полностью согласен, что другие средства гораздо лучше питона, я вот питон вообще не использую)

Честно говоря, сидели бы вы вечно в своем питоне.

Занимаетесь самовнушением? Python изначально разрабатывался как самый читабельный язык, так что не курите так больше. Большое комьюнити может состоять на 95% из школоты, как впрочем оно и есть в случае рэйлса. Идеология Pyramid, как впрочем и идеология Python, нацелена как раз таки на создание чётко работающего кода с очевидными связями между компонентами. Так что не надо бредить про скрытые баги в коде на Python.

Руби программы очень стабильны, это связано с высокой степенью модульности (повторного использования хорошо-оттестированного кода)

Относительно «хорошо-оттестированного кода» это вы погорячились. Им там и не пахнет. Профессионально написанные модули к рэйлсу можно пересчитать по пальцам, за то мелкого говна написанного школотой хоть отбавляй и рельсисты обожают вытянуть это говно из какого нибудь бложика и вставить заместо того что бы написать 10 строчек своего кода.

В виду отсутствия - несомненно)) И я полностью согласен, что другие средства гораздо лучше питона, я вот питон вообще не использую

Причём тут питон? Речь шла о тех нагромождениях конструкций которые есть в руби и которые никому нафиг не нужны на практике.

Python изначально разрабатывался как самый читабельный язык

Видимо в одночасье что-то пошло не так)

комьюнити может состоять на 95% из школоты

Тогда я бы предположил, что ты из дет.сада)

Относительно «хорошо-оттестированного кода» это вы погорячились.

пруф лол, похоже ты вообще не понимаешь о чем речь.

Причём тут питон?

при том, что он бесполезен.

С вами невозможно разговаривать - вы пишете бред без всяких аргументов. Приведите пример нечитаемого синтаксиса в Python.

Что касается излишней любви рельсистов использовать написанные третьими лицами модули по каждому чиху - зачастую написать несколько строчек своего кода решающего частный случай лучше чем заюзать модуль от третьих лиц т.к. есть, как показывает практика, огромный риск нарушить целостность системы - документация не может отображать всех ньюансов. В результате система разрастается до гигантских размеров и связи между компонентами становятся слишком усложнёнными.

Приведите пример нечитаемого синтаксиса в Python.

вот же:

написать несколько строчек своего кода решающего частный случай

А еще:

Почему бы не исправить portage?
Код portage слишком сломан, чтобы его можно было исправить. Это огромное месиво спагетти-образного процедурного кода без какого-либо дизайна. Он повсеместно и везде опирается на нестандартные уловки, поэтому любое изменение способно вызвать огромные нарушения работоспособности в, казалось бы, никак не связанных областях. Он практически целиком недокументирован, внутренние переменные нелепы и часто уже не отражают реалии, которые код выполняет в настоящее время.

— Ciaran McCreesh

проблема в том что вся эта система с формами, полями, виджетами, генерацией html'а разбросанной по классам, методам, субъективно переусложнена. тут легче какой-то хак поверх наваять и забить чем пробовать по бумажке все это реализовать, да так чтоб это реюзабельно вышло и кому-то пригодилось

Django — пациент скорее..? (комментарий)

Если бы можно было так просто взять и разорвать эти компоненты, заменить формы, например. Но ведь все связанно, в лучшем случае надо перепиливать целый слой. Короче, словив не иллюзорный разрыв жеппы я просто забил хрен, я не смог продолжать эту вакханалию.

Django — пациент скорее..? (комментарий)

А теперь покажи мне критику «непонятного кода» какого-нибудь руби проекта, клоун.

в питоне есть, как показывает практика, огромный риск нарушить целостность системы

Следствие слабых инструментов разработки питона, только и всего. Если конкретно питон плохо работает при высокой степени модульности, то это проблемы исключительно питона. Нечего перекладывать с больной головы на здоровую.

Прекратите вносить изменения в мои цитаты!!! Это просто не этично!

Написать спагетти код можно на любом языке. Или вы хотите сказать что в руби нельзя давать нелепые названия переменным? В дополнение в руби есть перлоподобные фичи которые помогут в написании нечитаемого кода.

Python отлично работает с модулями. Затрудняюсь представить себе ситуацию когда конфликт имён из разных модулей имел место в Python.

Качество модулей в Python по моему опыту на порядок выше чем в руби. Политика апдейтов также. Чего уж говорить если ваш рейлс регулярно обновляют внося кучу проблем и не удосужившись протестировать толком. Помню много было ситуаций с мелкими багами, например, если правильно помню при обновлении до какой то версии 2.3.x вместо сообщений об ошибках в формах начали выводиться какие то теги. И это был стабильный релиз!

Прекратите вносить изменения в мои цитаты

Не пиши того, что к руби не относится.

Написать спагетти код можно на любом языке.

На руби нет.

Или вы хотите сказать что в руби нельзя давать нелепые названия переменным?

Нет.

Рубиста придется еще заставлять писать некрасивый (но быстрый например) код. Это сродни мании. Иногда библиотеки лучше не использовать не потому, что они разрушают целостность, а потому что они могут работать чересчур медленно. Например вот http://www.youtube.com/watch?v=zEMfvCqVL4E - докладчик убеждает рубистов, что 10(без преувеличения) строк кода это не сложно. Короче, руби код, прежде всего понятный и красивый код - это идеология комьюнити.

Качество модулей в Python

Выше приведен (и разжеван) пример, где это не так. Как я уже сказал, в области web проекты питона отстают на несколько (4-5) лет, а другие области меня мало интересуют.

Охотно верю что в руби библиотеки работают чересчур медленно.

В чём проявляется отставание на 4-5 лет? В том что нет ненужных на практике модных в среде рубистов фич?

Ну и спагетти код не просто в руби а в приложении написанном под вами горячо любимый дырявый рэйлс я наблюдал лично! Не надо бредить, очевидно что его написание возможно на любом языке, по крайней мере на любом императивном языке.