> При падении рубля всё импортное (в т.ч. все товары и услуги, в производстве которых используется что-либо импортное) становится дороже.
А при укреплении рубля дешевеет что ли? Падения рубля — это скорее повод, чем причина, не секрет ведь, что крупные ретейлеры хэджируют свои валютные риски, т.е. без повышения цен они получат какой-то ущерб, только если будет падать среднегодовой курс рубля, а краткосрочные колебания курса их практически никак не затрагивают.
В общем, связь рублевых цен с курсом доллара гораздо слабее, чем принято втирать населению.
Какая вам разница до курса доллара в путешествии по Европе? Евро уже больше 2-х лет в районе 41 руб колеблется. Если сравнивать с курсом в июне прошлого года, то разница всего несколько копеек. Откуда рост курса в 1.5 раза?
Да и доллар прежде чем вырасти до текущего 32.5, упал с уровня 32, который был в декабре, январе.
Так они там разные, UX-дизайнеры весьма прилично получают и это правильно, т.к. спроектировать удобное взаимодействие гораздо сложнее (меньше людей на это способны), чем красиво его оформить.
Не забывайте, что там 60 тыс. долларов — это за год. Конечно, это всё равно больше, примерно в 2 раза, но ведь в США зарплаты всегда были в разы больше, чем в Москве. Сейчас разрыв в IT-области похоже имеет тенденцию к уменьшению.
Да, так даже лучше, единственный минус в том, что придётся написать подробную статью на тему распространённых паролей с отсылкой к статистическим данным. А то найдутся пользователи, которые даже запрет 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-дампов и логов не вспомнилось такого размера… Только зачем их в редакторе кода открывать?
А при укреплении рубля дешевеет что ли? Падения рубля — это скорее повод, чем причина, не секрет ведь, что крупные ретейлеры хэджируют свои валютные риски, т.е. без повышения цен они получат какой-то ущерб, только если будет падать среднегодовой курс рубля, а краткосрочные колебания курса их практически никак не затрагивают.
В общем, связь рублевых цен с курсом доллара гораздо слабее, чем принято втирать населению.
Да и доллар прежде чем вырасти до текущего 32.5, упал с уровня 32, который был в декабре, январе.
Если пользователь проигнорил, то это хотя бы его осознанный выбор, а заставлять насильно использовать сложный пароль уместно только для ограниченного круга сайтов, например для банковских.
Это очень странно, возможно Вы начали работу с СУБД сразу с 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-дампов и логов не вспомнилось такого размера… Только зачем их в редакторе кода открывать?