Pull to refresh
24
0
lovchy@lovchy

User

Send message
А потом еще и в тексте заметил туда же отсыл. Чтение по-диагонали до добра не доведет :(
Очень подробно тема раскрыта, спасибо.

P.S. Долго смотрел на все эти краники и квадратики с кривыми, а потом осенило: да это ж тот самый ithink из «Deadline» Тома Демарко. И графики очень близкие. Отличная, все-таки книга.
А теперь коммитим все это в апстрим. Перевод документации благое дело. Особенно когда оно централизовано и ведется прямо на оффициальном сайте. А разработчики всегда рады лишним рукам.
На велосипеде? На каком?
Они пытаются допиливать каждую мелочь до идеала (разумеется в их понимании). Тут опять же есть две политики, либо попытаться запихнуть в релиз как можно больше всего, достаточно плохо спроектированного, реализованного и оттестированного. А можно release early, release often. И при этом вставлять в релизы только то, что сделано очень хорошо. Они просто не успевают сделать все и сразу. При этом рынок и то, как устроен мир, врядли позволят 20 лет проектировать телефон, который еще потом непонятно будет ли актуален.

Поэтому, хочется верить, копи-паста не было.
Вы сделали мир немного лучше. Низкий поклон.
В википедии написано про схему таблицы. Понятно, что колонка — это вертикаль, а ряд — горизонталь. Но масштабируем мы не схему, а данные.

Представьте себе таблицу в экселе. Та же реляционная таблица. Вы добавляете новые ряды. Они появляются снизу. Соответственни таблица растет вниз. Низ — это вертикаль.

Я предлагаю уже закрыть этот разговор про вертикальность и горизонтальность. Это оффтоп.
«потому как мы разбиваем нашу таблицу по горизонтали, то есть по строкам таблицы»

Строки в таблице расположены вертикально ;]
Да, я давая ссылку смотрел на описание алгоритма, не взглянул на summary. Выше объяснил, что они имеют в виду под этим. И что имел я. Вопрос терминологии.
Тут есть некая игра слов. Это действительно horizontal partitioning, но vertical scaling, т.е. ноды доставляются вбок бесконечно, но сами данные из таблицы бьются по-вертикали.
Нет, именно вертикальное. Википедия / Shard.
А ну и тогда некорректно писать, что в Zend правил нет. Понятно, что их можно нарушить. Но это верно для любого фреймворка. Даже в, упоминаемых мной почти в каждом комменте этой ветки, рельсах ;].
Вы изменили мое отношение к этому фреймворку. Видимо за последнее время он действительно сильно развился. Если они тоже идут к Conventions over Configurations, набирают скорость и при этом умудряются качественно мейнтейнить код, за ними будущее. Обязательно копну его снова поглубже в ближайшее время, спасибо.
Что-то с моей речью в последнее время. То, что в Zend нет сложных сущностей — это не страшно. Это просто объясняет успех с кодом :].
Я его серьезно ковырял только первый раз. И время от времени теперь ставлю как-раз по описанному Вами принципу ;]. И раз такой способ есть и он кому-то удобен, значит они на правильном, на мой взгляд, пути. Клево.

«Профессионально написаный код» (никак не могу удержать от улыбки) — результат работы ограниченной команды людей. Посмотрите Yii. В нем пока тоже все хорошо. Таков мир, когда код пишет миллион людей, он за крайне редким исключением выглядит плохо.

А вот в случае зенда за это приходится расплачиваться ОЧЕНЬ низкой скоростью разработки. Мир вымрет пока они сделают full-stack. Вспомните за какой срок были созданы рельсы. И они все еще впереди планеты всей в вопросе «мы делаем вашу жизнь лучше и разработку проще». И PHP вообще ничем ответить не может :[.

Но самое страшное, что в Zend нет ВООБЩЕ ничего сложного. Одна из самых страшных задач фреймворка — удобный ORM. Потому что это один из 3-х китов. Это вам не классики-врапперы для SMTP-функций писать. Еще и поэтому его код _пока_ хорош.
Я сразу хочу попросить не реагировать на последний абзац как на красную тряпку. Это субъективное мнение и личный опыт. У меня он работал медленно, но поднимать тесты и доказывать это мне лень. За весь остальной базар отвечу ;].
Почему-то все разработчики, голосующие за ZF в один голос твердят, что свобода Zend — это плюс. Мой опыт показывает, что это очень и очень сильное заблуждение. Вы когда пишете проект на ZF, неужели директории проекта раскидываются как попало и то же происходит с именами в СУБД и коде? Врядли. Значит правила все-таки есть. Почему бы не дать другим ребятам придумать их за вас? Все-равно это просто семантика. В который кстати автор приложения может что-то не додумать. А вот фреймворк, который в разработке 3-й год наверняка на этом уже обжегся.

Ruby on Rails так стремительно дорос до состояния, в котором уже показывает зубы PHP из-за гениального подхода Conventions over Configurations. Все работает из коробки, просто следуй правилам. И не делай одну и ту же работу дважды. А вот Zend из коробки не работает. Нет ее, коробки.

Я бы вообще, честно говоря, не стал Zend с Yii и CI сравнивать. Скорее с PEAR (/me уворачивается от кучи помидоров из зала): те же яйца, вид сбоку. И покрашены в цвета Enterprise.

И алаверды, он все-таки заметно медленнее конкурентов. Аргумент «хотите скорости берите асм» — ересь до тих пор, пока Zend продолжает сливать тому же Yii по критерию «это у меня в продакшне работает хорошо, а это медленно».
Ух ты! Какой интересный экземпляр. Спасибо! Вполне возможно, что возьмем Quicky.
То как отрабатывает bootstrap для hello world показывает насколько фреймворк способен не тянуть за собой всякую ненужную функциональность. Это всего одна из кучи характеристик фреймворка. Не самая важная, но и не бесполезная: объем двигателя косвенно определяет расход бензина. Так вот там по ссылочке они четко дают понять, что сравнивают не скорость фреймворка. А скорость бутстрапа.

В итоге же фреймворки выбираются по набору характеристик. Из которых часть вообще жутко субъективная и сравнению не подлежит. Другую часть можно и надо тестировать. При этом, понятно, что это не цельное сравнение одного фреймворка с другим.

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Registered
Activity