Да, так даже лучше, единственный минус в том, что придётся написать подробную статью на тему распространённых паролей с отсылкой к статистическим данным. А то найдутся пользователи, которые даже запрет 100 самых популярных паролей сочтут самоуправством… Кстати, интересно какая будет вероятность ситуации, когда пользователь 3 раза пытается задать пароль и каждый раз попадает на легко подбираемый :-)
Можно выводить предупреждение типа «слишком простой пароль».
Если пользователь проигнорил, то это хотя бы его осознанный выбор, а заставлять насильно использовать сложный пароль уместно только для ограниченного круга сайтов, например для банковских.
> Мне как раз таки сложную выборку проще понять в AREL, это раз
Это очень странно, возможно Вы начали работу с СУБД сразу с ORM. Не вижу другого объяснения почему SQL-запрос может казаться сложнее, чем конкатенация кучи методов. Особенно с учётом того, что сложная выборка на ARel занимает обычно в 2-3 раза больше строк, чем на SQL.
> я легко переключаюсь между mysql, postgresql и sqlite
Зачастую это не более, чем самообман.
Сложные запросы, как правило, используют возможности конкретной СУБД. А если не использует, то запрос скорее просто длинный, а не сложный.
Хотя в целом соглашусь, что надо умело сочетать ORM c raw-SQL и не злоупотреблять ни тем, ни другим. Надо использовать то, что проще в конкретной ситуации. Я ни в коем случае не призываю везде использовать raw-SQL, т.к. это не менее глупо, чем везде использовать ARel.
Зависит от ситуации. Когда вы пишете сложную выборку или пакетное обновление по сложным критериям, вы ведь всё равно пишете это на SQL и от переписывания её на ARel никому лучше не станет, а читабельность упадёт до уровня «без бутылки не разберёшься». Как ни крути, для сложных запросов ничего элегантнее raw SQL пока не придумали.
> Если Вы не видите разницу в том, что код с примерами, с ссылками на похожие методы, с полным описанием всех функций (методов), то мне и объяснять дальше не стоит.
Фишка в том, что у RoR оно не менее полное, чем у к-л другого фреймворка.
Похожие методы — это вообще ваш личный термин. Что под этим понимается никто не в курсе, приведите хоть 3-4 примера.
> Я приводил пример с авто, так вот Вы как раз, похоже, из разряда автолюбителей-автомехаников, которые балдеют от автоВАЗа.
Не согласен. Есть два подхода к инструментам: потребительский и профессиональный.
В случае с веб-программированием потребительский подход реализуется в рамках CMS, всё остальное предполагает, что вы разбираетесь в устройстве инструментов, а не побежите в автосервис, если у вас бензин закончится.
Если в рамках ваших метафор, то я призываю программистов быть механиками «Формулы-1», а роль водителя уступить пользователям. А любители автоВАЗа в данном случае — это как раз те, кто изучает фреймворки по документации, т.к., не заглядывая в код, они так навсегда и останутся не более, чем любителями.
> И, знаете, все прекрасно получалось и получается — без знания внутренностей, со знанием что и как работает только из нормальной, хорошей документации.
Ну, ну… Сайты-визитки отлично получаются по документации. Когда напишете первое высоконагруженное приложение, тогда и поймёте как сильно заблуждались.
> Я думаю, что и вы далеко не уедете в любой сложной системе без документации.
Сложно только то, что непонятно. Если вам понятен исходный код системы, то она уже несложная.
> Пора бы понять, что документация — это благо, это необходимость, она помогает не отвлекаться на детали, а более продуктивно и качественно работать, заниматься своим делом, а не исследовать как и что когда-то кто-то сделал и пытаться вникнуть в детали.
Документация — это лишь описание представлений людей о том как работает код, причём далеко не всегда правильное и актуальное (особо отмечаю, что это касается абсолютно любой документации). Если она описывает код, на языке который вы плохо знаете, то документация — незаменимая вещь. Если же речь идёт о фреймворке на языке, который вы хорошо знаете, то лучшая документация для него — это его код.
> Возьмите для примера Yii, Kohana, Zend — там дела гораздо лучше с доками, чем у Ruby on Rails.
Ну это уже неимоверно толстый троллинг. Видимо дела там гораздо лучше исключительно потому что примеры на PHP :-)
Других «преимуществ» не видно.
> И зачем мне понимать внутреннее устройство работы фреймворк, чтобы работать с ним, скажите мне на милость?
Чтобы не забивать гвозди микроскопом и не строить велосипеды.
Ваша проблема в том, что Вы не понимаете самого важного: не «работать с ним», а «работать им», «решать задачи его средствами»!!! Фреймворк — это не вещь в себе, это инструмент, а точнее даже ящик с инструментами.
> Разве фреймворк не для того предназначен, чтобы облегчить работу программиста, а не наоборот нагружать его лишними деталями своего внутреннего устройства?
Фреймворк безусловно облегчит в разы работу тем, кто понимает как работают абстракции, которые он реализует. А тем, кто ещё и детально знает его устройство, облегчит работу в десятки раз. Всем остальным он только усложнит работу.
Серебряной пули не существует. Для новичка начинать с использования фреймворка — это тупиковая ветвь эволюции, потому что он не будет понимать почему что-либо работает так, а не иначе.
> Я лично без единой книги выучил php только по одному этому сайту.
Ну и что это доказывает? Знание языка самого по себе — это капля в программистских знаниях.
> Дело вкуса — придираться к названиям функций или нет
Разве ж это придирки? Это пример косяка в stdlib, коих там сотни… Это весьма критическая проблема — без документации вы в PHP и шагу не ступите, т.к. здравый смысл в stdlib отсутствует напрочь.
Вы постоянно сбиваетесь на сравнение языка с фреймворком. У любого фреймворка высокий порог вхождения, т.к. это априори инструмент для ускорения работы профессионалов, а не для новичков. Нравится или нет, но надо понимать внутреннее устройство фреймворка или хотя бы базовые паттерны, чтобы использовать его эффективно. Иначе абстракции так протекут, что захлебнётесь.
А что касается языков, то изучать их по документации вообще странная затея для новичка. Учебники для кого вообще пишут?
Я сам когда-то программировал на PHP и могу точно сказать, что у него дела с stdlib обстоят хуже некуда… Вы никогда не сможете объяснить новичку какого хрена strpos пишется без подчеркивания и принимает строку в первом аргументе, а str_replace — с подчеркиванием и принимает строку в третьем аргументе. Т.е. если новичок попытается понять логику построения stdlib в PHP, то у него мозг взорвётся. Не понимаю в каком месте тут низкий порог вхождения…
Где вы у gedit проблемы с недостатком плагинов нашли? Даже пакет плагинов специально под Rails-проекты есть github.com/gmate/gmate
Конечно этим набором список плагинов не ограничивается, на деле их на порядок больше, да и никто не мешает их писать самому на том же питоне.
P.S. Интересно, что за файлы на 5-50 Мб вы открываете в текстовом редакторе, да ещё и с необходимостью подсветки синтаксиса? Мне по первой ассоциации ничего кроме SQL-дампов и логов не вспомнилось такого размера… Только зачем их в редакторе кода открывать?
На мой взгляд, у каждого успешного инструмента есть две фазы:
1) Когда пачками добавляются новые фичи, и это всем весело… именно эту фазу педалирует автор статьи.
2) Когда инструмент используется для зарабатывания денег на коммерческих проектах. На этой фазе мало кому весело от появления новых фич, изменений в API и прочем. В этой фазе превалирует девиз «новые фичи — для новых проектов», а для существующих проектов должны быть очень весомые аргументы, чтобы затевать апгрейд. К примеру, в крупном проекте менять Jammit на Asset Pipeline и переписывать весь JavaScript на CoffeeScript практически никто не будет, т.к. во-первых это не несёт существенного профита, а во-вторых ни фига не весело…
В итоге кол-во существующих крупных проектов со временем достигает критического размера и те, кто раньше активно вводил новые фичи, становятся противниками дальнейших изменений. Грубо говоря, элитарная часть сообщества успокаивается, порог допуска к принятию решений повышается, а процедура введения новых фич максимально бюрократизируется. Это относится к любому ЯП, фреймворку и т.д.
P.S. Студентам, конечно, интереснее и полезнее возиться с проектами, у которых есть шашечки… Что не отменяет изучение и проверенных временем инструментов. Практикующим программистам сложнее находить время и желание для освоения каждого нового инструмента, поэтому и возникают разрывы и пропасти на последовательности принятия инноваций.
Я вот никогда не понимал желания использовать Python или Ruby для научных расчётов. Есть же Mapple, Matlab и другие специализированные инструменты для этих целей.
В конце концов язык программирования — это лишь средство… и знание Python/Ruby — вовсе не повод пытаться заниматься научными расчётами с их помощью
Функционал — это не самоцель.
Профессиональные программисты очень принципиальны и одним из их базовых принципов является YAGNI
Когда программист реализует неоговоренный функционал по собственной прихоти — это признак дилетантства, а не профессиональной гордости. Программист может решать как делать оговоренный функционал, но не должен решать что (какой набор фич) делать.
То, что Вы написали, никак не противоречит моему высказыванию…
За исключением терминологии.
В Agile не пишут ТЗ, а пишут функциональную спецификацию на основе сценариев использования на каждую итерацию.
А то, что Вы называете «предварительное ТЗ» — это в случае плохого ТЗ — набор блоков сайта, а в случае Agile набор т.н. пользовательских историй.
Все прелести сохраняются, но уходит вся «вода», которой практически во всех ТЗ, что я видел, было больше половины. Т.е. описывается не что нужно сделать, а как это должно работать в рамках ментальной модели пользователя.
Продуманного досконального ТЗ на крупных проектах в принципе не может быть…
В статье речь идёт о проектах из серии «написали и забыли», а когда проект разрабатывается годами, крутясь на production и реагируя на просьбы пользователей и всяческие исследования, то вам неизбежно придётся постоянно дорабатывать и переделывать 80% от его функционала. И чем раньше вы начнёте этим заниматься и чем более короткими итерациями, тем проще вам будет вести разработку с каждой итерацией и тем изящнее будет архитектура проекта.
Если пользователь проигнорил, то это хотя бы его осознанный выбор, а заставлять насильно использовать сложный пароль уместно только для ограниченного круга сайтов, например для банковских.
Это очень странно, возможно Вы начали работу с СУБД сразу с ORM. Не вижу другого объяснения почему SQL-запрос может казаться сложнее, чем конкатенация кучи методов. Особенно с учётом того, что сложная выборка на ARel занимает обычно в 2-3 раза больше строк, чем на SQL.
> я легко переключаюсь между mysql, postgresql и sqlite
Зачастую это не более, чем самообман.
Сложные запросы, как правило, используют возможности конкретной СУБД. А если не использует, то запрос скорее просто длинный, а не сложный.
Хотя в целом соглашусь, что надо умело сочетать ORM c raw-SQL и не злоупотреблять ни тем, ни другим. Надо использовать то, что проще в конкретной ситуации. Я ни в коем случае не призываю везде использовать raw-SQL, т.к. это не менее глупо, чем везде использовать ARel.
Фишка в том, что у RoR оно не менее полное, чем у к-л другого фреймворка.
Похожие методы — это вообще ваш личный термин. Что под этим понимается никто не в курсе, приведите хоть 3-4 примера.
> Я приводил пример с авто, так вот Вы как раз, похоже, из разряда автолюбителей-автомехаников, которые балдеют от автоВАЗа.
Не согласен. Есть два подхода к инструментам: потребительский и профессиональный.
В случае с веб-программированием потребительский подход реализуется в рамках CMS, всё остальное предполагает, что вы разбираетесь в устройстве инструментов, а не побежите в автосервис, если у вас бензин закончится.
Если в рамках ваших метафор, то я призываю программистов быть механиками «Формулы-1», а роль водителя уступить пользователям. А любители автоВАЗа в данном случае — это как раз те, кто изучает фреймворки по документации, т.к., не заглядывая в код, они так навсегда и останутся не более, чем любителями.
> И, знаете, все прекрасно получалось и получается — без знания внутренностей, со знанием что и как работает только из нормальной, хорошей документации.
Ну, ну… Сайты-визитки отлично получаются по документации. Когда напишете первое высоконагруженное приложение, тогда и поймёте как сильно заблуждались.
> Я думаю, что и вы далеко не уедете в любой сложной системе без документации.
Сложно только то, что непонятно. Если вам понятен исходный код системы, то она уже несложная.
> Пора бы понять, что документация — это благо, это необходимость, она помогает не отвлекаться на детали, а более продуктивно и качественно работать, заниматься своим делом, а не исследовать как и что когда-то кто-то сделал и пытаться вникнуть в детали.
Документация — это лишь описание представлений людей о том как работает код, причём далеко не всегда правильное и актуальное (особо отмечаю, что это касается абсолютно любой документации). Если она описывает код, на языке который вы плохо знаете, то документация — незаменимая вещь. Если же речь идёт о фреймворке на языке, который вы хорошо знаете, то лучшая документация для него — это его код.
Ну это уже неимоверно толстый троллинг. Видимо дела там гораздо лучше исключительно потому что примеры на PHP :-)
Других «преимуществ» не видно.
> И зачем мне понимать внутреннее устройство работы фреймворк, чтобы работать с ним, скажите мне на милость?
Чтобы не забивать гвозди микроскопом и не строить велосипеды.
Ваша проблема в том, что Вы не понимаете самого важного: не «работать с ним», а «работать им», «решать задачи его средствами»!!! Фреймворк — это не вещь в себе, это инструмент, а точнее даже ящик с инструментами.
> Разве фреймворк не для того предназначен, чтобы облегчить работу программиста, а не наоборот нагружать его лишними деталями своего внутреннего устройства?
Фреймворк безусловно облегчит в разы работу тем, кто понимает как работают абстракции, которые он реализует. А тем, кто ещё и детально знает его устройство, облегчит работу в десятки раз. Всем остальным он только усложнит работу.
Серебряной пули не существует. Для новичка начинать с использования фреймворка — это тупиковая ветвь эволюции, потому что он не будет понимать почему что-либо работает так, а не иначе.
> Я лично без единой книги выучил php только по одному этому сайту.
Ну и что это доказывает? Знание языка самого по себе — это капля в программистских знаниях.
> Дело вкуса — придираться к названиям функций или нет
Разве ж это придирки? Это пример косяка в stdlib, коих там сотни… Это весьма критическая проблема — без документации вы в PHP и шагу не ступите, т.к. здравый смысл в stdlib отсутствует напрочь.
А что касается языков, то изучать их по документации вообще странная затея для новичка. Учебники для кого вообще пишут?
Я сам когда-то программировал на PHP и могу точно сказать, что у него дела с stdlib обстоят хуже некуда… Вы никогда не сможете объяснить новичку какого хрена strpos пишется без подчеркивания и принимает строку в первом аргументе, а str_replace — с подчеркиванием и принимает строку в третьем аргументе. Т.е. если новичок попытается понять логику построения stdlib в PHP, то у него мозг взорвётся. Не понимаю в каком месте тут низкий порог вхождения…
Конечно этим набором список плагинов не ограничивается, на деле их на порядок больше, да и никто не мешает их писать самому на том же питоне.
P.S. Интересно, что за файлы на 5-50 Мб вы открываете в текстовом редакторе, да ещё и с необходимостью подсветки синтаксиса? Мне по первой ассоциации ничего кроме SQL-дампов и логов не вспомнилось такого размера… Только зачем их в редакторе кода открывать?
1) Когда пачками добавляются новые фичи, и это всем весело… именно эту фазу педалирует автор статьи.
2) Когда инструмент используется для зарабатывания денег на коммерческих проектах. На этой фазе мало кому весело от появления новых фич, изменений в API и прочем. В этой фазе превалирует девиз «новые фичи — для новых проектов», а для существующих проектов должны быть очень весомые аргументы, чтобы затевать апгрейд. К примеру, в крупном проекте менять Jammit на Asset Pipeline и переписывать весь JavaScript на CoffeeScript практически никто не будет, т.к. во-первых это не несёт существенного профита, а во-вторых ни фига не весело…
В итоге кол-во существующих крупных проектов со временем достигает критического размера и те, кто раньше активно вводил новые фичи, становятся противниками дальнейших изменений. Грубо говоря, элитарная часть сообщества успокаивается, порог допуска к принятию решений повышается, а процедура введения новых фич максимально бюрократизируется. Это относится к любому ЯП, фреймворку и т.д.
P.S. Студентам, конечно, интереснее и полезнее возиться с проектами, у которых есть шашечки… Что не отменяет изучение и проверенных временем инструментов. Практикующим программистам сложнее находить время и желание для освоения каждого нового инструмента, поэтому и возникают разрывы и пропасти на последовательности принятия инноваций.
В конце концов язык программирования — это лишь средство… и знание Python/Ruby — вовсе не повод пытаться заниматься научными расчётами с их помощью
Профессиональные программисты очень принципиальны и одним из их базовых принципов является YAGNI
Когда программист реализует неоговоренный функционал по собственной прихоти — это признак дилетантства, а не профессиональной гордости. Программист может решать как делать оговоренный функционал, но не должен решать что (какой набор фич) делать.
Как должен выглядеть интерфейс пользователя это не программисту решать, эта задача вне его компетенции.
> Ну, по причине, например, собственной гордости или как это назвать.
Я бы назвал эту причину раздутым самомнением.
За исключением терминологии.
В Agile не пишут ТЗ, а пишут функциональную спецификацию на основе сценариев использования на каждую итерацию.
А то, что Вы называете «предварительное ТЗ» — это в случае плохого ТЗ — набор блоков сайта, а в случае Agile набор т.н. пользовательских историй.
Все прелести сохраняются, но уходит вся «вода», которой практически во всех ТЗ, что я видел, было больше половины. Т.е. описывается не что нужно сделать, а как это должно работать в рамках ментальной модели пользователя.
В статье речь идёт о проектах из серии «написали и забыли», а когда проект разрабатывается годами, крутясь на production и реагируя на просьбы пользователей и всяческие исследования, то вам неизбежно придётся постоянно дорабатывать и переделывать 80% от его функционала. И чем раньше вы начнёте этим заниматься и чем более короткими итерациями, тем проще вам будет вести разработку с каждой итерацией и тем изящнее будет архитектура проекта.