нет — в php пока нельзя. я говорил о других языках.
По поводу вашего утверждения: в «маленьком» проекте, где каждый из нескольких участников может полностью владеть кодом это не так важно как в большом проекте, где каждый занимается своей частью и дальше контрактов компонентов не может видеть. А т.к. поддержание любого порядка требует дополнительных ресурсов — то в маленьком проекте от некоторых практик (например нестрого соблюдать правило Деметры) можно «контролируемо» отказаться. Это может не иметь фатальных последствий, при этом немного сэкономить времени в ситуации когда это очень важно.
Есть мнение, что в средних и больших проектах, которые будут жить и поддерживаться длительное время хорошей практикой считается политика «скрывать всё по-умолчанию». Т.е. по умолчанию — всё private (в очень больших — ещё и final — чтобы меньше «думать»). Если есть какие-то явные основания то protected или public. В языках, где namespace не только пространство имён но и один из инструментов для инкапсуляции — и классы по умолчанию хорошо бы делать package-private (доступные только классам из того же namespace)
«Расширенный текучий интерфейс»
$images->SetWidth(100)->SetHeight(100);
Обычно называется «chained calls». разве нет?
«Это (MVC) прекрасная модель построения сайта. Именно сайта. Но вот когда речь заходит о построении, на его основе веб-приложения, увы, ощущаются его ограничения»
Вы меня простите, но MVC появился когда и о сайтах то мало кто задумывался и продолжает сейчас успешно применяться. И уж тем-более MVC и «chained calls» — это вещи ну совсем уж параллельные, никак друг на друга не влияющие
> Они как раз утверждают что «применение аспектов обычно ограничивается» ваше неверно.
Пробежался по статье по диагонали. Нашёл много текста говорящего о том, что «мол да — не ограничивается, что для аспектов есть много других хороших применений», но не нашёл ни одного убедительного примера. В случае с фильтром попытка показать преимущества аспектной реализации перед реализацией интерфейса выглядит надуманной.
Если у вас есть материалы об успешном использовании аспектов — будет интересно узнать (только просьба — больше не кидать ссылки на документы подобные тому с ibm)
Причём — если в java реализация динамических прокси выглядит обычно пугающе, то в php подобная техника является обычным делом благодаря magic-методам.
«Судя по популярности.....»
Насколько я знаю, AOP в «традиционных» языках имеет весьма ограниченное применение в силу того, что очень легко так, что код один, а происходит совсем другое. В Java — это отчасти компенсируется IDE которая подсказывает, что вот «здесь» ещё и аспекты вызываются. На даже не смотря на поддержку IDE — применение аспектов обычно ограничивается: логированием, декларативным управлением транзакциями, кешированием.
Но юмор ситуации в том, что если мы в архитектуре опираемся на SOLID, то декларативное управление транзакциями, кеширование и отчасти логгирование — мы можем легко и явно (или чуть менее явно — внутри IOC-контейнера) реализовать и без аспектов. Так так ли нужны аспекты в php?
Там речь шла о «девочке-представителе» заказчика. В реальной жизни у заказчика часто может не найтись другого представителя.
Что же до того, о чём пишете Вы: «поставил над опытными разработчиками девочку-манагершу». Вы так удивляетесь, как будто никогда с таким не сталкивались в релаьной жизни)
При чём тут agile. Да вы правы — не причём. Мой комментарий относился к практике asolntsev который писал, что у них в компании «разработчики общаюсь непосредственно с клиентом»
Простите, не совсем понял с чем в моём утверждении Вы не согласны.
asolntsev написал, что у них в компании «разработчики общаюсь непосредственно с клиентом», на что я сказал, что такая организация может приводить к печальным последствиям.
Мне показалось, что вы в своём комментарии пишете о том же. Нет?
Не совсем так. Я говорил о том, что допускать представителя заказчика до плотной работы с разработчиками может давать плохие результаты. Инкапсуляция команды «внутри менеджера» всё же «безопасней».
Что же касается внутрикомандного взаимодействия таких «звезд», то:
если руководитель группы/проекта не занимается ерундой, а работает со своими людьми — то опять же можно мягко и постепенно донести до своих звезд 2 мысли:
1)Все могут ошибаться и звезда в том числе. И когда человек ведет себя как «задница» — ему становится очень сложно признать свои ошибки. Это вредит отношением в коллективе и авторитету звезды.
2)В команде у нас специалисты разного уровня. Да. Большинство из них не знает что такое монады. Но дело в том, что большая часть работы в любом проекте — скучная рутина. И эти «незнающие монад» люди делают значительную часть этой грязной работы, давая возможность звезде читать про свои драгоценные монады.
Впрочем — всё это в равной мере относится к любому виду процесса. Agile тут совсем не причём.
>Вы ничего не путаете?
Нет. Я ведь не писал, что это «единственная причина».
Из утверждения «полицейские берут взятки» не следует что «все полицейские берут взятки».
По поводу ситуации с командой. Я всё же придерживаюсь мнения, что проекты обычно не растут как дикий плющ и не появляются ниоткуда. И если руководитель действительно «умница» — то наверно уж он приложит усилия чтобы набрать в команду более подходящих людей. Или если ему достался проект после другого руководителя — либо найти общий язык либо мягко заменить источник гангрены. «Я вижу, что вы очень опытный разработчик. Вы хорошо работаете, и заслуживаете повышения. Но к сожалению — в нашем проекте вам некуда расти выше. И мы это понимаем. И понимаем, что вам возможно было бы интересней перейти в другой проект. Если вы решите искать новое место работы — мы готовы предоставить вам рекомендации в обмен, на помощь в поиске и/или подготовки замены для вас». Ну и всё в таком духе.
В статью под заголовком «Почему Agile вам не подходит» я бы написал пожалуй: Потому, что где-то в цепи управления у нас затесался упертый, бестактный, бескомпромиссность идиот. Процесс не может быть более «гибким», чем самый «негибкий» участник-руководитель этого процесса.
Если у вас это работает и работает «хорошо» — всё хорошо)
В моём мире, опытные разработчики и люди умные в академическом смысле часто бывают склонны к интеллектуальному иллитизму. Проще говоря активно придерживаются мнения, что «я умный (что в общем-то верно если говорить CS и околоCSных вещах), а эта „девочка“ — »манагерша проекта" — представитель заказчика — мммм… «неумная»."
В такой ситуации — поведение «программиста» при общении с «заказчиком» становится — неконструктивным. «Программист» своей микромиимкой, жестами, и интонациями невербально выражает глубокое сожаление от того, что ему приходится общаться с этой бестолочью. Девушка-«манагер» — такое негативное поведение чувствует и (она ведь тоже самый обычный человек) — отвечает неконструктивным поведением: агрессией, требованиями в форме ультиматумов и прочей бескомпромиссностью. И всё — положительная обратная связь. Все проиграли.
Ну и субъективно — такое нарушение инкапсуляции приводит к тем же результатам, что и при проектировании классов.
Хм. Есть мнение, что если компания и команда, не останавливается сделав 20% работы и получив 80% результата — то все разговоры в которых используется слово «эффективно» в разных формах, не более чем bull-shiting.
Ещё немного смущает заголовок, в части «адаптивного управления». А как может быть какое-то другое?.. Даже в том же водопаде, никто не запрещает корректировать курс при появлении новых обстоятельств.
Забавно. «Какбэ» работа и псевдо-продуктивность. Когда вспоминаю как олдскульные автокадеры делали чертежи вбивая команды на клавиатуре с огромной скорость — все эти фантазии дизайнеров о том как выглядит работа и что такое продуктивность ничего кроме разочарования не вызывают.
А главное — когда у нас появятся аккумуляторы с большей плотностью энергии чем сейчас, чтобы питать все эти глупости — найдутся занятия поинтересней, чем бесконечно елозить пальцами по стеклу.
Ох. Неужели этот выбор прям настолько важен, что определяет успех или неудачу продукта, и выбрав одно, изменить в будущем это будет очень сложно? Очевидно что нет. На успех/провал продукта это никак не влияет, а современный уровень развития технологий позволяет нам менять одно на другое без заметных усилий (естественно при условии, что мы помним про инкапсуляцию и SRP и стараемся их придерживаться). Тогда какая разница? Зачем писать об этом статьи
А можно вопрос: зачем? «Понадобилось сделать репликацию несколькими мастер-серверами с mysql, чтобы данные со всех них грузились на один слэйв-сервер.»
И например рассматривался ли вариант с цепочной репликацией и BLACKHOLE (и если да, то чем не подошёл)?:
MASTER1 -> MASTER2,BLACKHOLE1 — > MASTER3,BLACKHOLE1,BLACKHOLE2 ->......->MASTER_N,BLACKHOLE1...BLACKHOLE_N-1 -> SLAVE
Такой вариант проще конфигурировать и обслуживать и никаких скриптов.
Формально у такой цепочки ниже надежность, но мне кажется что для агрегатора некоторый downtime не критичен. Точней так: мне кажется что нет большой разницы между тем, что 30 минут не поступают данные репликации (которые потом подтянутся) и тем, что 30 минут не поступают данные от одного из мастеров — в том смысле что в обоих этих случаях агрегированные значения будут отсутствовать/неверны
Мысли от КО:
Как можно «замотивировать» человека кроме как предложив ему непропорционально много денег? Никак) Всё что можно сделать — узнать что интересует человека, и рассказать ему как вектор интересов компании проецируется на вектор его интересов (на всякий случай: они совпадают ооочень редко) и как достижение интересов компании способствует достижению интересов человека.
Из этого вытекает, что сам по себе вопрос на собеседовании: «почему вы хотите работать в нашей компании» — кажется уже не таким глупым по сути, но всё портят слова в которые этот вопрос облачен.
По поводу вашего утверждения: в «маленьком» проекте, где каждый из нескольких участников может полностью владеть кодом это не так важно как в большом проекте, где каждый занимается своей частью и дальше контрактов компонентов не может видеть. А т.к. поддержание любого порядка требует дополнительных ресурсов — то в маленьком проекте от некоторых практик (например нестрого соблюдать правило Деметры) можно «контролируемо» отказаться. Это может не иметь фатальных последствий, при этом немного сэкономить времени в ситуации когда это очень важно.
$images->SetWidth(100)->SetHeight(100);
Обычно называется «chained calls». разве нет?
«Это (MVC) прекрасная модель построения сайта. Именно сайта. Но вот когда речь заходит о построении, на его основе веб-приложения, увы, ощущаются его ограничения»
Вы меня простите, но MVC появился когда и о сайтах то мало кто задумывался и продолжает сейчас успешно применяться. И уж тем-более MVC и «chained calls» — это вещи ну совсем уж параллельные, никак друг на друга не влияющие
Пробежался по статье по диагонали. Нашёл много текста говорящего о том, что «мол да — не ограничивается, что для аспектов есть много других хороших применений», но не нашёл ни одного убедительного примера. В случае с фильтром попытка показать преимущества аспектной реализации перед реализацией интерфейса выглядит надуманной.
Если у вас есть материалы об успешном использовании аспектов — будет интересно узнать (только просьба — больше не кидать ссылки на документы подобные тому с ibm)
Причём — если в java реализация динамических прокси выглядит обычно пугающе, то в php подобная техника является обычным делом благодаря magic-методам.
Насколько я знаю, AOP в «традиционных» языках имеет весьма ограниченное применение в силу того, что очень легко так, что код один, а происходит совсем другое. В Java — это отчасти компенсируется IDE которая подсказывает, что вот «здесь» ещё и аспекты вызываются. На даже не смотря на поддержку IDE — применение аспектов обычно ограничивается: логированием, декларативным управлением транзакциями, кешированием.
Но юмор ситуации в том, что если мы в архитектуре опираемся на SOLID, то декларативное управление транзакциями, кеширование и отчасти логгирование — мы можем легко и явно (или чуть менее явно — внутри IOC-контейнера) реализовать и без аспектов. Так так ли нужны аспекты в php?
Что же до того, о чём пишете Вы: «поставил над опытными разработчиками девочку-манагершу». Вы так удивляетесь, как будто никогда с таким не сталкивались в релаьной жизни)
При чём тут agile. Да вы правы — не причём. Мой комментарий относился к практике asolntsev который писал, что у них в компании «разработчики общаюсь непосредственно с клиентом»
asolntsev написал, что у них в компании «разработчики общаюсь непосредственно с клиентом», на что я сказал, что такая организация может приводить к печальным последствиям.
Мне показалось, что вы в своём комментарии пишете о том же. Нет?
Что же касается внутрикомандного взаимодействия таких «звезд», то:
если руководитель группы/проекта не занимается ерундой, а работает со своими людьми — то опять же можно мягко и постепенно донести до своих звезд 2 мысли:
1)Все могут ошибаться и звезда в том числе. И когда человек ведет себя как «задница» — ему становится очень сложно признать свои ошибки. Это вредит отношением в коллективе и авторитету звезды.
2)В команде у нас специалисты разного уровня. Да. Большинство из них не знает что такое монады. Но дело в том, что большая часть работы в любом проекте — скучная рутина. И эти «незнающие монад» люди делают значительную часть этой грязной работы, давая возможность звезде читать про свои драгоценные монады.
Впрочем — всё это в равной мере относится к любому виду процесса. Agile тут совсем не причём.
Нет. Я ведь не писал, что это «единственная причина».
Из утверждения «полицейские берут взятки» не следует что «все полицейские берут взятки».
По поводу ситуации с командой. Я всё же придерживаюсь мнения, что проекты обычно не растут как дикий плющ и не появляются ниоткуда. И если руководитель действительно «умница» — то наверно уж он приложит усилия чтобы набрать в команду более подходящих людей. Или если ему достался проект после другого руководителя — либо найти общий язык либо мягко заменить источник гангрены. «Я вижу, что вы очень опытный разработчик. Вы хорошо работаете, и заслуживаете повышения. Но к сожалению — в нашем проекте вам некуда расти выше. И мы это понимаем. И понимаем, что вам возможно было бы интересней перейти в другой проект. Если вы решите искать новое место работы — мы готовы предоставить вам рекомендации в обмен, на помощь в поиске и/или подготовки замены для вас». Ну и всё в таком духе.
В моём мире, опытные разработчики и люди умные в академическом смысле часто бывают склонны к интеллектуальному иллитизму. Проще говоря активно придерживаются мнения, что «я умный (что в общем-то верно если говорить CS и околоCSных вещах), а эта „девочка“ — »манагерша проекта" — представитель заказчика — мммм… «неумная»."
В такой ситуации — поведение «программиста» при общении с «заказчиком» становится — неконструктивным. «Программист» своей микромиимкой, жестами, и интонациями невербально выражает глубокое сожаление от того, что ему приходится общаться с этой бестолочью. Девушка-«манагер» — такое негативное поведение чувствует и (она ведь тоже самый обычный человек) — отвечает неконструктивным поведением: агрессией, требованиями в форме ультиматумов и прочей бескомпромиссностью. И всё — положительная обратная связь. Все проиграли.
Ну и субъективно — такое нарушение инкапсуляции приводит к тем же результатам, что и при проектировании классов.
Ещё немного смущает заголовок, в части «адаптивного управления». А как может быть какое-то другое?.. Даже в том же водопаде, никто не запрещает корректировать курс при появлении новых обстоятельств.
А главное — когда у нас появятся аккумуляторы с большей плотностью энергии чем сейчас, чтобы питать все эти глупости — найдутся занятия поинтересней, чем бесконечно елозить пальцами по стеклу.
это не кольцо
здесь нет master-master репликаций. толькоmaster-slave
И например рассматривался ли вариант с цепочной репликацией и BLACKHOLE (и если да, то чем не подошёл)?:
MASTER1 -> MASTER2,BLACKHOLE1 — > MASTER3,BLACKHOLE1,BLACKHOLE2 ->......->MASTER_N,BLACKHOLE1...BLACKHOLE_N-1 -> SLAVE
Такой вариант проще конфигурировать и обслуживать и никаких скриптов.
Формально у такой цепочки ниже надежность, но мне кажется что для агрегатора некоторый downtime не критичен. Точней так: мне кажется что нет большой разницы между тем, что 30 минут не поступают данные репликации (которые потом подтянутся) и тем, что 30 минут не поступают данные от одного из мастеров — в том смысле что в обоих этих случаях агрегированные значения будут отсутствовать/неверны
Как можно «замотивировать» человека кроме как предложив ему непропорционально много денег? Никак) Всё что можно сделать — узнать что интересует человека, и рассказать ему как вектор интересов компании проецируется на вектор его интересов (на всякий случай: они совпадают ооочень редко) и как достижение интересов компании способствует достижению интересов человека.
Из этого вытекает, что сам по себе вопрос на собеседовании: «почему вы хотите работать в нашей компании» — кажется уже не таким глупым по сути, но всё портят слова в которые этот вопрос облачен.