1) куча левых сущностей.
2) не прозрачность для разработчика. Тоесть я понятия не имею(без просмотра всего кода ОRМ) как и почему оно строит запросы. А зачастую что бы получить то что надо приходится танцевать с бубном.
3) Писать оптимизированные запросы куда проще на чистом SQL чем на ОRМ.
4) Скорость выполнения.
5) Работа ORM меняется от версии к версии, SQL код работает одинаково всегда(изменение БД во внимание не берем).
6) ORM очень тяжко работают с мультипроцессорностью и асинхронностью, куча багов, и странных манипуляций.
7) KISS
8) Даже и не пытайтесь делать миграцию на рабочем проекте с помощью ORM.
ORM — это обобщенная фиговина, HL работает с заточенными вещами. Если вы говорите да пофиг купим еще 100 серваков то это нифига не HL.
HL это когда вам говорят вот у нас есть старенький целерон и он должен тянуть 1к юзеро онлайн. А когда вам такое скажут, то вы начинаете не то что ORM выкидывать, а большую часть функционала языка.
Для примера раскажу древнюю историю с моей молодости. Работал я в банке и крутили мы на движе Zend Framework код для сотрудников. Возникла ситуация сделать экспорт в CSV файла на 50мб. Я даже не стад ничего писать а взял и сдела экспорт через клас фрейма(который сертифицирован под ентерпрайз). Каково же было мое удивление когда при генирации файла скрипт выжрал всю оперативу на серваке(8ГБ). Как оказалось чудо модуль на каждую запятую генерил по обьекту и в итоге кол-во обьектов своим весом просто вешало сервак.
Переписав без этой чудо абстракции код, буквально на 5 строчек, получил мего выиграш произвоодитльности.
Этот маленький пример показывает разницу между контроируемым кодом и неконтролируемым. Любая абстракция это снижение контроля, а снижение контроля ведет к проблемам, особенно в HL.
32 запроса на страницу? о_О 1000 онлайн и 32к запросов что по сути около 150-320к опсов(на примере GAE). Под таким натиском любой сервак ляжет. У мну юзеров 8-10к и генерят они только 4-7к опсов. И это не сайт а игра.
А что можно тестировать в большом проекте без моков и фреймов? И вообще какой смысл тестировать то что вероятнее всего и не поламается.
Ну тоесть тестировать сеттер и геттер смысла нет, а вот парсер запроса или менеджер памяти есть.
Тесты не ловят ошибки, они только дают какуюто вероятность того что вы не создали новых. Ошибки же ловятся дебагерами и логгерами на стадии нагрузочного и системного тестирования. Особые гурманы еще делают фаззи-тесты.
Почему то все думают что тесты решают все проблемы. Но в реальности плохо написанный тест создаст еще больше проблем чем если бы его не было вовсе. Поэтому тесты требу.т не меньшего внимания и серйозности подхода как напиание самого продакшен кода. В итоге нормальный тест занимает раз в 5 больше времени чем написание самого функционала. А это говорит о том что такие пряники досутпны далеко не каждому проекту.
А я провел это время куда позитивнее… вместо того что бы снова сидеть за компом и говорить о все том же… взял сноуборд и катал весь день пока не отнялись ноги. Нельзя такие дни убивать на обыденность)
ну как бы да, но по сути и нет. Я к примеру могу повернуть тур типа как проехать по тем местам где ще никто не ездил и снять видос всего этого. С понтом суть проекта видос. А по факту я буду собирать деньги на путешествие а видос так и быть скину с гоу про)
Парень по сути сделал то же самое, сделает пару фоток, а потом тусить)
Постановка не верна. Нужно скорее так:
«Я хочу посетить самые высокие места планеты, сьесть на них бутерброд с колбасой, запить ананасовым соком, снять фотки процеса поедания, а потом сделать из них кино.» Ну и просить надо тыщ 20 что бы не подумали что вы не в теме)
Насколько помню правила размещения то проект не может оплачивать ваши путешествия и отдых. Каким макаром ета тема прокатила?
Пойду думать как организовать тур по евразии на мотах вне дорог.
Мы пошли немного другим путем. Что бы не тратить время на перевод мы генерим уже переведенные конфиги и просто юзаем их для нужной локали, тоже и для javascript. Gettext просто не сильно оптимальное решение для серверов которые не держат базу в памяти, например для php.
Я такую технологию юзал еще до гугла и линкедина… она логична. Есть еще как минимум gettext, которому 100 лет в обед. Посему расказ о приходе к технологии не ясен.
Я вот млин не понимаю неужели Apple так тяжело сделать что бы тестироват приложения можно было бесплатно, что за жлобство млин 100уе чисто что бы попробовать?
в математике вам предлагают думать. Формулы, теорему, аксиомы не обязательны для решения, вы в принципе можите вывести все сами.
Да и в любом случае все эти формулы, аксимомы,… без практики забываются через день. Именно практика дает понимание того зачем они нужны, где и как их применять.
«Теория мой друг суха, но зеленеет жизни древо.» Фауст
2) не прозрачность для разработчика. Тоесть я понятия не имею(без просмотра всего кода ОRМ) как и почему оно строит запросы. А зачастую что бы получить то что надо приходится танцевать с бубном.
3) Писать оптимизированные запросы куда проще на чистом SQL чем на ОRМ.
4) Скорость выполнения.
5) Работа ORM меняется от версии к версии, SQL код работает одинаково всегда(изменение БД во внимание не берем).
6) ORM очень тяжко работают с мультипроцессорностью и асинхронностью, куча багов, и странных манипуляций.
7) KISS
8) Даже и не пытайтесь делать миграцию на рабочем проекте с помощью ORM.
ORM — это обобщенная фиговина, HL работает с заточенными вещами. Если вы говорите да пофиг купим еще 100 серваков то это нифига не HL.
HL это когда вам говорят вот у нас есть старенький целерон и он должен тянуть 1к юзеро онлайн. А когда вам такое скажут, то вы начинаете не то что ORM выкидывать, а большую часть функционала языка.
Для примера раскажу древнюю историю с моей молодости. Работал я в банке и крутили мы на движе Zend Framework код для сотрудников. Возникла ситуация сделать экспорт в CSV файла на 50мб. Я даже не стад ничего писать а взял и сдела экспорт через клас фрейма(который сертифицирован под ентерпрайз). Каково же было мое удивление когда при генирации файла скрипт выжрал всю оперативу на серваке(8ГБ). Как оказалось чудо модуль на каждую запятую генерил по обьекту и в итоге кол-во обьектов своим весом просто вешало сервак.
Переписав без этой чудо абстракции код, буквально на 5 строчек, получил мего выиграш произвоодитльности.
Этот маленький пример показывает разницу между контроируемым кодом и неконтролируемым. Любая абстракция это снижение контроля, а снижение контроля ведет к проблемам, особенно в HL.
Ну тоесть тестировать сеттер и геттер смысла нет, а вот парсер запроса или менеджер памяти есть.
Тесты не ловят ошибки, они только дают какуюто вероятность того что вы не создали новых. Ошибки же ловятся дебагерами и логгерами на стадии нагрузочного и системного тестирования. Особые гурманы еще делают фаззи-тесты.
Парень по сути сделал то же самое, сделает пару фоток, а потом тусить)
«Я хочу посетить самые высокие места планеты, сьесть на них бутерброд с колбасой, запить ананасовым соком, снять фотки процеса поедания, а потом сделать из них кино.» Ну и просить надо тыщ 20 что бы не подумали что вы не в теме)
Пойду думать как организовать тур по евразии на мотах вне дорог.
Да и в любом случае все эти формулы, аксимомы,… без практики забываются через день. Именно практика дает понимание того зачем они нужны, где и как их применять.
«Теория мой друг суха, но зеленеет жизни древо.» Фауст