Можно выводить предупреждение типа «слишком простой пароль».
Если пользователь проигнорил, то это хотя бы его осознанный выбор, а заставлять насильно использовать сложный пароль уместно только для ограниченного круга сайтов, например для банковских.
> Мне как раз таки сложную выборку проще понять в 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% от его функционала. И чем раньше вы начнёте этим заниматься и чем более короткими итерациями, тем проще вам будет вести разработку с каждой итерацией и тем изящнее будет архитектура проекта.
А чем Вам так не нравится первая картинка? Вполне себе рабочий, простой магазин. Полно случаев когда нужно именно это. Достаточно идиотическая ситуация, если программист будет единолично додумывать что нужно заказчику, попутно увеличив срок реализации в несколько раз. В итоге всё кончится тем, что заказчик, увидев реализацию по второй картинке, скажет «я этого не заказывал» и будет на 100% прав.
С другой стороны не менее дурацкая ситуация имеет место когда оценку сроков и бюджета делают до утверждения макетов интерфейса.
В Ruby-проектах отношение к контрибьютерам лучше.
Хотя действительно лучше начинать с небольших тикетов из issues на github-аккаунте проекта.
Ну а если вы хотите добавить новую фичу, то либо делайте её отключаемой, либо сначала обсудите это в тех же github issues или на lighthouse или на uservoice, в зависимости от проекта.
Когда Вы без спроса и согласования пытаетесь добавить новую функциональность в чужой проект, то это конечно странно само по себе, хотя иногда может прокатить, если функциональность действительно полезная.
А что мешает получить практику? Выберите один из популярных OpenSource-проектов на Rails и сделайте туда хотя бы десяток коммитов…
Это сразу увеличит Вашу привлекательность для работодателей в разы. При том что Вам это практически ничего не стоит, если квалификация позволяет включиться в разработку существующего проекта.
Если пользователь проигнорил, то это хотя бы его осознанный выбор, а заставлять насильно использовать сложный пароль уместно только для ограниченного круга сайтов, например для банковских.
Это очень странно, возможно Вы начали работу с СУБД сразу с 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% от его функционала. И чем раньше вы начнёте этим заниматься и чем более короткими итерациями, тем проще вам будет вести разработку с каждой итерацией и тем изящнее будет архитектура проекта.
С другой стороны не менее дурацкая ситуация имеет место когда оценку сроков и бюджета делают до утверждения макетов интерфейса.
Хотя действительно лучше начинать с небольших тикетов из issues на github-аккаунте проекта.
Ну а если вы хотите добавить новую фичу, то либо делайте её отключаемой, либо сначала обсудите это в тех же github issues или на lighthouse или на uservoice, в зависимости от проекта.
Когда Вы без спроса и согласования пытаетесь добавить новую функциональность в чужой проект, то это конечно странно само по себе, хотя иногда может прокатить, если функциональность действительно полезная.
Это сразу увеличит Вашу привлекательность для работодателей в разы. При том что Вам это практически ничего не стоит, если квалификация позволяет включиться в разработку существующего проекта.