А ну слава богу:)

А то у меня складывается впечатление что ты в чём-то разбираешься, но я не могу понять в чём

У меня с терминологией очень плохо, а что касается апи класса , то да, есть всегда на основе публичных методов независимо от того есть ли интерфейс или нет, в php за счёт возможности использования магических методов (неявного обращения к методам и свойствам класса ) можно не реализовывать интерфейс, такая практика приносит очень большую путаницу , но я так делаю в небольших проектах где нет ничего сложного. P.S. Можете назвать меня гонокодером, но иногда так проще

значит не будет юзать это говно

@fes0r напиши в каких ситуациях ты все же допускаешь использование трейтов, я например использую их для включения общих методов , например шаблон синглтон (абстрактный), в php есть косяк с поздним статическим связыванием, в наследнике приходится переопределять статическое свойство для хранения инстанса, трейт лишён этой болезни, или тот же мой НЕправильный декоратор с магическими методами вместо реализации конкретного интерфейса может быть трейтом, в общем хотелось бы несколько примеров - показаний к использованию трейтов.

ты ведь знаешь, что синглтон - зло, да?

ты ведь знаешь, что синглтон - зло, да?

Да, как и сервис локатор на статике, но если поддержание порядка зависимостей не столь важно системе , то допускаю такое использование, но что это зло конечно знаю. P.S. Я в общем для маленьких несложных проектов , которые надо быстро накидать допускаю использование всякого бардака и неявных конструкций))) В больших так гадить конечно нельзя, это равносильно рытью могилы себе

@fes0r напиши в каких ситуациях ты все же допускаешь использование трейтов, я например использую их для включения общих методов , например шаблон синглтон (абстрактный), в php есть косяк с поздним статическим связыванием, в наследнике приходится переопределять статическое свойство для хранения инстанса, трейт лишён этой болезни, или тот же мой НЕправильный декоратор с магическими методами вместо реализации конкретного интерфейса может быть трейтом, в общем хотелось бы несколько примеров - показаний к использованию трейтов.

трейт "лишен" этого недостатка потому что это копипаста кода и не более, оно никак на типы не влияет. В целом допускаю трейты там, где приходится выбирать меньшее из двух зол. То есть как временное решение для устранения дублирования при рефакторинге легаси. При этом в определенный момент этот трейт должен исчезнуть. Так же есть второстепенные вещи и бойлерплейт. Мне например нравится выносить кастомные ассерты в трейт, ибо... там логики никакой нет - все делигируется. Опять же - у меня правило простое - лишь бы небыло protected стэйта с доступом из подтипов. Что бы не плодить неопределенное поведение и уменьшать связанность. Что до сингелтонов - маленький проект или нет - это так себе оправдание. Сингелтоны в том виде в котором ты описал появляются только в двух ситуациях - ограничение на ресурсы (когда тебе просто нельзя иметь два инстанса одного класса, что для php маловероятная задача) либо бардак в управлении зависимостями. В целом и DI со всякими автовайрингами провацирует разработчиков разводить бардак, потому я не очень преветствую это дело... но юзаю ибо ленивый

трейт "лишен" этого недостатка потому что это копипаста кода и не более, оно никак на типы не влияет. В целом допускаю трейты там, где приходится выбирать меньшее из двух зол. То есть как временное решение для устранения дублирования при рефакторинге легаси. При этом в определенный момент этот трейт должен исчезнуть. Так же есть второстепенные вещи и бойлерплейт. Мне например нравится выносить кастомные ассерты в трейт, ибо... там логики никакой нет - все делигируется. Опять же - у меня правило простое - лишь бы небыло protected стэйта с доступом из подтипов. Что бы не плодить неопределенное поведение и уменьшать связанность. Что до сингелтонов - маленький проект или нет - это так себе оправдание. Сингелтоны в том виде в котором ты описал появляются только в двух ситуациях - ограничение на ресурсы (когда тебе просто нельзя иметь два инстанса одного класса, что для php маловероятная задача) либо бардак в управлении зависимостями. В целом и DI со всякими автовайрингами провацирует разработчиков разводить бардак, потому я не очень преветствую это дело... но юзаю ибо ленивый

Помнишь я писал про проект в котором каждый байт кода мне дорог ( файловый менеджер), как раз я все эти трейты и использовал, т.к. там именно случай с ограниченными ресурсами, где дублирование кода непозволительная роскошь. В целом спасибо за расширенный ответ!

Помнишь я писал про проект в котором каждый байт кода мне дорог ( файловый менеджер), как раз я все эти трейты и использовал, т.к. там именно случай с ограниченными ресурсами, где дублирование кода непозволительная роскошь. В целом спасибо за расширенный ответ!

ммм.... "ограниченные ресурсы" - это типа у тебя один COM порт и тебе нельзя что бы из двух мест с ним одновременно работали... хер знает короч. Врядли это твой случай

в целом даже в таком случае можно без сингелтонов

Имеется ввиду насколько можно сжать код не теряя функциональность

трейт "лишен" этого недостатка потому что это копипаста кода и не более, оно никак на типы не влияет. В целом допускаю трейты там, где приходится выбирать меньшее из двух зол. То есть как временное решение для устранения дублирования при рефакторинге легаси. При этом в определенный момент этот трейт должен исчезнуть. Так же есть второстепенные вещи и бойлерплейт. Мне например нравится выносить кастомные ассерты в трейт, ибо... там логики никакой нет - все делигируется. Опять же - у меня правило простое - лишь бы небыло protected стэйта с доступом из подтипов. Что бы не плодить неопределенное поведение и уменьшать связанность. Что до сингелтонов - маленький проект или нет - это так себе оправдание. Сингелтоны в том виде в котором ты описал появляются только в двух ситуациях - ограничение на ресурсы (когда тебе просто нельзя иметь два инстанса одного класса, что для php маловероятная задача) либо бардак в управлении зависимостями. В целом и DI со всякими автовайрингами провацирует разработчиков разводить бардак, потому я не очень преветствую это дело... но юзаю ибо ленивый

Про какой бардак речь?

Имеется ввиду насколько можно сжать код не теряя функциональность

опять же - тот факт что у тебя дублирование может говорить о том, что ты неверно провел границы между модулями.

если тебе будет спокойнее - почти никогда эти самые границы правильно (во всяком случае всегда) нельзя провести)

Про какой бардак речь?

обычный такой бардак когда все проблемы из глобального доступа к зависимостям и отсутствия контроля за ними.

в целом даже в таком случае можно без сингелтонов

Можно, di плюс методы в базовом контроллере для получения, но для использования в функционале длинные обращения для меня критичны, пример: $this->filesystem()-save() у меня сделано через функцию бога ga('f')->save() где f короткое название сервиса , понимаю что такая экономия похожа на байтовую шизофрению, но так запись короче, соответственно там скрыт пул сервисов.

Можно, di плюс методы в базовом контроллере для получения, но для использования в функционале длинные обращения для меня критичны, пример: $this->filesystem()-save() у меня сделано через функцию бога ga('f')->save() где f короткое название сервиса , понимаю что такая экономия похожа на байтовую шизофрению, но так запись короче, соответственно там скрыт пул сервисов.

складывается ощущение что ты там что-то нехорошее писал, ибо всем должно быть глубоко насрать на размер кода выполняющегося на сервере

Можно, di плюс методы в базовом контроллере для получения, но для использования в функционале длинные обращения для меня критичны, пример: $this->filesystem()-save() у меня сделано через функцию бога ga('f')->save() где f короткое название сервиса , понимаю что такая экономия похожа на байтовую шизофрению, но так запись короче, соответственно там скрыт пул сервисов.

Это ты на php оптимизируешь?

Это ты на php оптимизируешь?

звучит как какой-то шэл скрипт

фу

Это ты на php оптимизируешь?

Да

Нет, но там такие методы есть)

А в пыхе же на каждый запрос загружается фреймворк со всем добром. fpm он только держит пул запущенных процессов?

Лан. Ты хочешь про скалу?

Не понимаю ddd

Может кто простыми словами сказать

http://lurkmore.to/%D0%9C%D0%B0%D1%88%D0%B8%D0%BD%D0%B0_%D0%A1%D1%83%D0%B4%D0%BD%D0%BE%D0%B3%D0%BE_%D0%B4%D0%BD%D1%8F

Может кто простыми словами сказать

DDD это когда ты ведешь разработку с упором на бизнес, а не на техническую сторону вопроса. Типа не if впихнуть а бизнес спросить как им лучше. Соответственно что бы было удобнее появляются такие вещи как единый язык. Ты штуки в коде называешь максимально близко к тому как бизнес это описывает, что бы можно было (в идеале) почитать стэкхолдеру код в слух и он бы сказал что так оно должно работать или нет. Ну и ограниченные контексты (потому что разным стэкхолдером нужны разные штуки). В целом DDD это лишь маркетинговая херня поверх адекватной декомпозиции и анализа требований/бизнес анализа совмещенного с уменьшением стоимости перевода требований в код.

если ты просто из джирки тасочки берешь да репозиториями со всякими сущностями обмазываешься и при этом не особо вникаешь в предметную область - это называется оверинженеринг и хуйня а не ddd

DDD это когда ты ведешь разработку с упором на бизнес, а не на техническую сторону вопроса. Типа не if впихнуть а бизнес спросить как им лучше. Соответственно что бы было удобнее появляются такие вещи как единый язык. Ты штуки в коде называешь максимально близко к тому как бизнес это описывает, что бы можно было (в идеале) почитать стэкхолдеру код в слух и он бы сказал что так оно должно работать или нет. Ну и ограниченные контексты (потому что разным стэкхолдером нужны разные штуки). В целом DDD это лишь маркетинговая херня поверх адекватной декомпозиции и анализа требований/бизнес анализа совмещенного с уменьшением стоимости перевода требований в код.

Ты вообще чем занимаешь, зная всё это ?

тоже так думаю

Ты вообще чем занимаешь, зная всё это ?

пишу бложики на похапе, как и все тут

пишу бложики на похапе, как и все тут

С такими познаниями бложики не пишут )

а где доказательства того что я понимаю о чем говорю?)

wordpress наше все

Конечно. Для таких людей даже специальный язык программирования придумали. Называется Go. Я не шучу. Действительно, целью создания языка Go была попытка вовлечения в написание кода студентов и стажеров Google, которые не могут освоить C++. Python им не подходил по производительности, нужно было что-то иное, и в Google придумали Go. Как оказалось, очень много людей готовы на нем писать, потому что он очень простой. Но какой ценой достигнута эта простота? Нам дают не нормальный язык программирования, а его очень урезанную версию — в нем нет практически никаких сложных концептов by design. Нет дженериков, нет такого понятия, как исключения и т.д. И поклонников такого подхода много. Но есть и другие разработчики, и для них является проблемой то, что есть языки, в которых нет баланса: ты можешь делать простые вещи просто, а сложные ты не можешь делать вообще никак. Или хотя бы через боль — приходится бороться с инструментом, чтобы что-то сделать. Вот здесь, мне кажется, и кроется проблема управления сложностью. Хорошее высказывание

И речь даже не про Go, а про второй абзац)

Конечно. Для таких людей даже специальный язык программирования придумали. Называется Go. Я не шучу. Действительно, целью создания языка Go была попытка вовлечения в написание кода студентов и стажеров Google, которые не могут освоить C++. Python им не подходил по производительности, нужно было что-то иное, и в Google придумали Go. Как оказалось, очень много людей готовы на нем писать, потому что он очень простой. Но какой ценой достигнута эта простота? Нам дают не нормальный язык программирования, а его очень урезанную версию — в нем нет практически никаких сложных концептов by design. Нет дженериков, нет такого понятия, как исключения и т.д. И поклонников такого подхода много. Но есть и другие разработчики, и для них является проблемой то, что есть языки, в которых нет баланса: ты можешь делать простые вещи просто, а сложные ты не можешь делать вообще никак. Или хотя бы через боль — приходится бороться с инструментом, чтобы что-то сделать. Вот здесь, мне кажется, и кроется проблема управления сложностью. Хорошее высказывание

Значит как хорошо, что язык это всего-лишь инструмент. И можно использовать подходящий инструмент под задачу.

И речь даже не про Go, а про второй абзац)

Дженерики ж завезут в го, че ныть?

Ну и да - хочешь ты того или нет - индустрии нужны такие языки, потому что разработчики такие.

Ну и да - хочешь ты того или нет - индустрии нужны такие языки, потому что разработчики такие.

да, суть именно в этом ну и electron туда же

ИНДУСтрия

зачем всем говорить что ты расист?

это тонкий намёк, что go появился из-за Сундара?

Зачем говорить что украинцы любят сало? Потому что это правда)

Так же и с индусами. Культура.

Это не культура а стереотипные представления)

Если в сале есть мясо, то я его тож люблю)

а солёное мясо без сала тоже ничего

Это не культура а стереотипные представления)

а как формируются стереотипы?

а как формируются стереотипы?

из чувства превосходства

Сейчас масс медиа

Раньше сарафанное радио видимо

я смотрю вы с индусами не работали

или с китайцами

Причём не важно на реальных признаках инфа основана или на выдуманных

меня нашел индус и начал писать мне про вордпресс

Раньше сарафанное радио видимо

ну то есть один чувак увидео один инцидент и стал говорить что они все такие и все поверили? Или все же имеет место статистика?

ну то есть один чувак увидео один инцидент и стал говорить что они все такие и все поверили? Или все же имеет место статистика?

имеет место чувство превосходства

ну то есть один чувак увидео один инцидент и стал говорить что они все такие и все поверили? Или все же имеет место статистика?

Зависит от влияния, возможностей чувака

ты же не будешь говорить что все белые плохо программируют даже с большим количеством негативного опыта

Я например не видел чтобы мои соотечественники катались на медеведе бухая водочкой на красной площади, но...

Я например не видел чтобы мои соотечественники катались на медеведе бухая водочкой на красной площади, но...

ага, а узбеки плов не едят)0

имеет место чувство превосходства

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

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

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

все это намного сложнее, есть миллионы факторов, вплодь до погоды на улице, которые существенно влияют на то как делаются дела. А от того грустно наблюдать за менеджерами которые почитали PMBOK наискосок и вперед управлять людьми

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

в индии неплохо с образованием, но там и людей в разы больше. От того получаем большое количество недоразработчиков которых держат десятками тысяч, и лишь небольшой процент из них что-то могут. Как по мне в целом по миру статистика примерно одинаковая, а дальше роль играет количество людей в конкретном регионе задействованное.

но я не вижу ничего плохого в шутках построенных на стереотипах (до тех пор пока это шутки и они не влияют на принятие важных решений вроде найма). Но да, я думаю что среди жителей калифорнии я быстрее найду нормального разработчика (ввиду конкуренции) нежели среди жителей Дэли

в индии неплохо с образованием, но там и людей в разы больше. От того получаем большое количество недоразработчиков которых держат десятками тысяч, и лишь небольшой процент из них что-то могут. Как по мне в целом по миру статистика примерно одинаковая, а дальше роль играет количество людей в конкретном регионе задействованное.

у нас вон тоже есть норм прогеры, а есть сайтоклепатели

все так, дальше просто проэцируешь свои 10K разработчиков на 1KK там

кстати про управление. У меня на работе вводют SCRUM. Но что-то сомневаюсь, что из этого что-то выйдет. Надо бы что-то почитать на эту тему =\ С чего начать? С agile manifesto?

кстати про управление. У меня на работе вводют SCRUM. Но что-то сомневаюсь, что из этого что-то выйдет. Надо бы что-то почитать на эту тему =\ С чего начать? С agile manifesto?

1. agile manifesto - это типа собрались N человек и решили первым делом сформировать манифест их объединяющий. То есть это не то ради чего они собирались а просто способ описать идеи которые общие для них. Ознакомиться с ним стоит просто что бы подумать согласен ты с этими идеями, почему и т.д. На этом ценность этого манифеста заканчивается. 2. по поводу скрама - есть scrum guide - он небольшой, почитай ознакомься. 3. Если скрам навязывают сверху - то это не будет работать. У вас просто появится больше митингов (или меньше, хз что у вас было до этого), возможно вы начнете заниматься херней типа скрам покера, но в целом ничего не поменяется.

сам по себе скрам - неплохая штука. Но большинство почему-то думают что это вот "процесс которому надо следоваь" хотя это больше фреймворк на базе которого ты уже будешь формировать процесс. Хочешь процесс - бери RUP - там все описано.

скажем за те 6 лет что я по скраму работаю у меня было только пара проектов где дэйли это дэйли. Сразу советую погуглить на тему разницы между дэйли и статус митингами. Спойлер - менеджеров на дэйли быть не должно. Это чисто митинг команды, строго по делу, точка синхронизации (которая возможно вам не нужна, это уже команда должна решать, особенно если команда распределенная там больше вариантов)

скажем за те 6 лет что я по скраму работаю у меня было только пара проектов где дэйли это дэйли. Сразу советую погуглить на тему разницы между дэйли и статус митингами. Спойлер - менеджеров на дэйли быть не должно. Это чисто митинг команды, строго по делу, точка синхронизации (которая возможно вам не нужна, это уже команда должна решать, особенно если команда распределенная там больше вариантов)

Мы это называли стэндап

а стэндапы на которых все сидели были?)

Были планирования перед спринтами которые на два дня порой затягиыаличь

Там все сидели

У утренняя пяти минутка для раз рабов была токв

то есть если обобщить ошибки котторые я видел при внедрении скрама: - "скрам решит все наши проблемы потому что это процесс!" - скрам не про процесс, он про то что бы команда оставалась в фокусе. Многие менеджеры вводя скрам продолжают менять приоритеты и постоянно менять скоуп спринта. Если это происходит - ценности от скрама нету. - "Стори поинты как идеальные часы" - типичная ошибка когда люди раньше оценивали в часах и им сказали оценивать в поинтах - они и будут продолжать оценивать в часах. Хотя стори поинты они не про время а про сложность. То есть 10 задач по 1 сторипоинту по времени займту не столько же времени сколько 2 по 5. - Статус митинги вместо дэйли с тупыми вопросами вида "кто что сделал, что собирается делать и т.д." - отсутствие грумингов, когда разбираться как и что делать приходится по ходу дела. По хорошему на плэннинг задача уже должна приходить проработанной и все детали должны быть выяснены ДО что бы не тратить потом время. Тут хорошо подходят всякие specification by example и прочие штуки, мокапы кликабельные и т.д. что бы быстрее выяснять что нужно

в индии неплохо с образованием, но там и людей в разы больше. От того получаем большое количество недоразработчиков которых держат десятками тысяч, и лишь небольшой процент из них что-то могут. Как по мне в целом по миру статистика примерно одинаковая, а дальше роль играет количество людей в конкретном регионе задействованное.

мне сложно с тобой на эту тему дискутировать, т.к. этим надо серьёзно заниматься чтобы что-то внятное сказать. С ходу конечно сразу возникают вопросы на тему "Какой линейкой измерить уровень образования?" и "Если сейчас в индии высокий уровень образования - значит ли это, что те люди, которые сейчас там работают программерами получили это образование? (т.к. в тот момент когда они учились такого уровня образования ещё могло не быть)". И вообще то что у нас в расее в школах фигачат - это порой ужасный мрак, хотя у нас более менее образованная страна. Вообще система основанная на знаниях - сильно устарела, это даже и всякие там методисты признают. Но человекам очень сложно всё это менять =\

Были планирования перед спринтами которые на два дня порой затягиыаличь

у меня максимум по 4 часа были