Во многом я с вами согласен. Те пункты — это выдержки из статьи и с какими-то из них можно согласиться, да и просто интересно мнение «другой стороны».
ORM это абстракция/инкапсуляция т.е. теоретически можно инкапсулировать как SQL так и NoSQL и не знать ни один из них, однозначно нельзя сказать будет ли лучше со знанием основ или нет. Например, вы можете не знать как устроена машина, но водить можете. Если вы будете изучать строение авто, то не известно поможет ли вам сэкономить деньги, скажем, на починке, то потраченное на изучение время.
«Как я уже говорил он эффективен когда у вас мало данных много действий» — безусловно.
«Кто вам сказал что это лучше? Оно лучше на очень малом спектре задач.» — момент спорный. Можно мыслить реляционно и тогда реляционная БД в большинстве случаев будет для вас лучше, а можно мыслить документами, тогда мнение может измениться. Я ни в коем случае не говорю, что NoSQL > SQL.
«Кеширование объектов спасает» — вы предлагаете обход/маскировку проблемы :)
Недавно прочел ORM is an anti-pattern мнения автора статьи в чем-то пересекается с вашим. Вкратце плюсы-минусы:
1. ORM проще понять, чем SQL (можно и не знать SQL если использовать ORM)
2. Он эффективен на ранних стадиях (по быстренькому чего-нить написать)
3. Если приложение усложняется, то все плюсы ORM гаснут — приходиться учить SQL, дописывать…
4. 20+% проектов ломают абстракцию ORM
5. Объекты — это не адекватный способ представления реляционной структуры
6. Если ваши данные — объект, то лучше использовать NoSQL-решения
7. Из-за реляционной природы появляются накладные расходы при создании объекта
Почитайте, достаточно интересное мнение + интересные отзывы в коментах
В книгах про все не прочитать. Огромное количество информации в статьях. Не у всех есть время и деньги на написание книг, а вот статью может написать каждый разработчик :) Думаю, что блоги разработчиков, даже твиттер, может быть более полезным, чем книги (говорю в контексте JavaScript).
Соглашусь, что молотком сложно изучать строение молекул. Но уж лучше знать 1 язык доскональна — с глубоким знанием поймешь подойдет он для конкретной задачи или нет, чем N языков поверхностно — да будешь знать принципы, заложенные в языки, но напишешь ли хорошую программу в стиле данного языка?! Понятно, что базовые понятия ты будешь знать и реализуешь так или иначе говнокод алгоритм. Я уверен, что при поверхностном изучении каждый будет писать на одном языке в стиле другого — это как пересесть левого руля на правый или с мотоцикла на авто и водить с крыши.
Вот примеры смешения стиля:
1. UglifyJS / lib / parse-js.js (Lisp → JavaScript) — чистый функциональный стиль, годно, но сложно разобраться
2. binary-parser (??? → JavaScript) — ахтунг, лучше не открывать… на понятно на чем писал человек, но так не пишут на JavaScript
Я выступаю за качество знаний, но не говорю о том, что нужно упереться в один язык и писать на нем всю жизнь. Знаешь свой язык на высоком уровне — изучи другой, возможно он больше понравится. Конечно, в случае поиска языка (после ВУЗа часто ищут на чем бы писать) мой совет, безусловно, не подходит.
12. Доскональна изучите тот язык на котором вы программируете сейчас, уберите все пробелы в понимании, разберитесь как работает каждый оператор даже если он интуитивно понятен (привет instanceof из JavaScript). Это будет на много полезнее чем пункт 1. Часто знают результат функции/оператора, но не знают почему это так — появляется куча бредовых мнений (echo быстрее print) и куча вопросов, ответы на которые не дают понимания сути проблемы (часто дают решение, но не объясняют почему так).
1. Нужен хотя бы один язык основанный на прототипном наследовании, из актуальных: ECMAScript (JavaScript)
ECMAScript взрывает мозг, тем кто не знаком с прототипным делегирующим наследованием. Не поленитесь почитать как все устроено, уверяю, вас ждёт много открытий.
Сейчас с HTML5 History API мы можем отлавливать кнопки вперед, назад, используя метод pushState и событие popstate. В статье все хорошо описано. И в примере все работает (потыкайте по картинкам, а потом нажмите кнопку назад/вперед). HTML5 History API похож на location.hash magic, но только без магии и вместо хеша мы имеем реальный url, который можем кому-нибудь отправить или загрузить реальный документ тем же wget'ом.
Контроллер связывается с моделью при инициализации контроллера. В том пред примере на самом деле не показано откуда берется this.model
Если посмотреть на «Пример: Список Todo», то все становится понятнее:
window.TodoView = Backbone.View.extend({
// ...
});
window.AppView = Backbone.View.extend({
// ...
// Создание элемента туду. Создаем вид и засовываем в `<ul>`
addOne: function(todo) {
var view = new TodoView({model: todo}); // <<<
this.$("#todo-list").append(view.render().el);
}
//...
});
Поясню чтобы не путать читающих. Вот это 'pewpew'[0] = 'P' невозможно без кардинальных изменений в всем JavaScript. Потому, что строка в JavaScript — примитивный тип и то, что у строки можно вызывать методы на самом деле «магия» интерпретатора, который делает следующее:
// Ваш код
var a = 'abc';
var b = a.toUpperCase();
console.log(a, b); // "abc", "ABC"
// Интерпретатор понимает его как
var a = 'abc';
// Создает временный объект. Метод toUpperCase вызывается у временного объекта.
var temp_a = new String(a);
var b = temp_a.toUpperCase();
free(temp_a); // такой функции нет, она для примера
console.log(a, b); // "abc", "ABC"
Ещё:
// Ваш код
var a = 'abc';
a[0] = 'A';
console.log(a); // "abc"
// Интерпретатор понимает его как
var a = 'abc';
// Создает временный объект. Переменная [0] создается у временного объекта
var temp_a = new String(a);
temp_a[0] = 'A';
free(temp_a); // такой функции нет, она для примера
console.log(a); // "abc"
Т.е. свое состояние примитив не может изменять, поэтому 'pewpew'[0] = 'P' невозможно без кардинальных изменений.
Как-то я категорично. Смягчу фразу «Такой фичи нет — значит она не нужна повсеместно». В 99% случаев не нужна, поэтому и не включили в «Ядро». Единственное место, где замена символа с строке сократила бы код — это capitalize:
Вполне разумный аргумент, намекающий на то, что разработчики языка заботятся о тех, кто будет на нем писать. ECMAScript сейчас бурно развиваются, в нем появляются новые фичи, которые действительно нужны, а не так чтобы «вот в PHP можно заменить символ строки, а в JavaScript нельзя — дайте!!!11». Ещё раз «Такой фичи нет — значит она не нужна». Я имею большой опыт разработки на JavaScript и ещё ни разу не сталкивался с проблемой замены N-го символа в строке, поэтому я не удивлен отсутствием такого функционала.
ORM это абстракция/инкапсуляция т.е. теоретически можно инкапсулировать как SQL так и NoSQL и не знать ни один из них, однозначно нельзя сказать будет ли лучше со знанием основ или нет. Например, вы можете не знать как устроена машина, но водить можете. Если вы будете изучать строение авто, то не известно поможет ли вам сэкономить деньги, скажем, на починке, то потраченное на изучение время.
«Как я уже говорил он эффективен когда у вас мало данных много действий» — безусловно.
«Кто вам сказал что это лучше? Оно лучше на очень малом спектре задач.» — момент спорный. Можно мыслить реляционно и тогда реляционная БД в большинстве случаев будет для вас лучше, а можно мыслить документами, тогда мнение может измениться. Я ни в коем случае не говорю, что NoSQL > SQL.
«Кеширование объектов спасает» — вы предлагаете обход/маскировку проблемы :)
1. ORM проще понять, чем SQL (можно и не знать SQL если использовать ORM)
2. Он эффективен на ранних стадиях (по быстренькому чего-нить написать)
3. Если приложение усложняется, то все плюсы ORM гаснут — приходиться учить SQL, дописывать…
4. 20+% проектов ломают абстракцию ORM
5. Объекты — это не адекватный способ представления реляционной структуры
6. Если ваши данные — объект, то лучше использовать NoSQL-решения
7. Из-за реляционной природы появляются накладные расходы при создании объекта
Почитайте, достаточно интересное мнение + интересные отзывы в коментах
говнокодалгоритм. Я уверен, что при поверхностном изучении каждый будет писать на одном языке в стиле другого — это как пересесть левого руля на правый или с мотоцикла на авто и водить с крыши.Вот примеры смешения стиля:
1. UglifyJS / lib / parse-js.js (Lisp → JavaScript) — чистый функциональный стиль, годно, но сложно разобраться
2. binary-parser (??? → JavaScript) — ахтунг, лучше не открывать… на понятно на чем писал человек, но так не пишут на JavaScript
Я выступаю за качество знаний, но не говорю о том, что нужно упереться в один язык и писать на нем всю жизнь. Знаешь свой язык на высоком уровне — изучи другой, возможно он больше понравится. Конечно, в случае поиска языка (после ВУЗа часто ищут на чем бы писать) мой совет, безусловно, не подходит.
1. Нужен хотя бы один язык основанный на прототипном наследовании, из актуальных: ECMAScript (JavaScript)
ECMAScript взрывает мозг, тем кто не знаком с прототипным делегирующим наследованием. Не поленитесь почитать как все устроено, уверяю, вас ждёт много открытий.
Если бы мы немного подправили код на сервере, то могли бы получать состояние как при закрытии.
location.hashmagic, но только без магии и вместо хеша мы имеем реальный url, который можем кому-нибудь отправить или загрузить реальный документ тем же wget'ом.this.modelЕсли посмотреть на «Пример: Список Todo», то все становится понятнее:
'pewpew'[0] = 'P'невозможно без кардинальных изменений в всем JavaScript. Потому, что строка в JavaScript — примитивный тип и то, что у строки можно вызывать методы на самом деле «магия» интерпретатора, который делает следующее:Ещё:
Т.е. свое состояние примитив не может изменять, поэтому
'pewpew'[0] = 'P'невозможно без кардинальных изменений.Но ради одного такого «бонуса» придется отказаться от обратной совместимости (сейчас действует политика совместимости со старыми версиями).