а 3й?

деревья тоже разные бывают )

Materialized Path

деревья тоже разные бывают )

ОЧЕНЬ РАЗНЫЕ

но о видах деревьях и о некоторых в отдельности

можно целые стримы делать

я это прекрасно понимаю

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

если учесть что я делал в начале и что сейчас то мне кажется уровень растет)

а 3й?

Materialized Path

https://habrahabr.ru/post/46659/

вот к слову статья на эту тему

их очень много )))

естественно много) ты ж не открыл америку :D

так сейчас ничего нового не открыть

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

ога, как в начале 90х.... всем хватит пару мегабайт на веки

все правильно делаешь

с опытом постоянно возвращаешься к азам

и всегда интересно как делают другие

например инет магаз

в чем проблема?

нет проблем

ну то есть, "интернет магазин" слишком большая штука, там можно например имутабельными делать отдельные элементы. Или вообще все (event sourcing)

я про то что "Двери" достаточно абстрактный пример

в реале оно не про двери

ну а инет магаз - класика реального проекта

шо, опять?

todo list

вон ими уже весь интенет забит этими todo list

в жопу тудулисты )

это слишком просто

суть в том что у разных людей

разные навыки и знания

кому то и двери сложно, кому то слишком просто

ну тудулист ближе к реальности чем дверь )

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

это слишком просто

для реального примера нужны и сроки реальные. Никто не хочет ни делть ни смотреть стрим на неделю

и всегда интересно как делают другие

Не все понимают чужой код (если вы про это конечнг)

для реального примера нужны и сроки реальные. Никто не хочет ни делть ни смотреть стрим на неделю

++++

для реального примера нужны и сроки реальные. Никто не хочет ни делть ни смотреть стрим на неделю

Легко )

в видео про имутабельность я и так много раз повторялся и говорил одно и тоже)))

а пример с дверьми Сергей подсказал

он наиболее наглядный

да возможно никак не связанный с web

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

но я об этом упоминал в видео про

ну мне показалось что в воздухе остался висеть вопрос - а как это применить

psr/http-message

ну мне показалось что в воздухе остался висеть вопрос - а как это применить

да я тебя понял, я это постараюсь учесть

в конце надо показывать как это реально применяется например в web

ага было бы круто

но в пхп это мало применяется

например для дат в времени есть Carbon а есть Cronos

второе имутабельное

первое мутабельное

а api примерно одинаковое но это очень удачно в дайджесте написано)

но в пхп это мало применяется

))

например я следующий стрим хочу начать с класического круга (frontend, backed, data base или ui, логика, данные и тд )

что это все приложение или сервис или инструмент

и он состоит из этих компонентов которые между собой взаимодействуют

пользователь взаимодействует например с видимой частью

происходят события и их обработка

например это redux и тут задвигать можно о redux

на несколько часов

далее при обработке событий идет обращение к backend

и тут уже backend работает в режиме Request, Responce

ERROR: S client not available

и тут внутри бэкенда уже может быть ооп, solid, ddd и тд (все то что сейчас в хайпе)

а бэкенд уже взаимодействует с данными например по средствам sql или чего то другова

а сегодня я покажу что слой данных содержит в себе кучу всего

и если попробовать рассказать вот это вот все сразу

запланируйте еще про оптимизации в похапе: low memory usage, high speed и т.д. и т.п. ощень актуально сейчас.. вот прям сейчас ^_^

то стрим очень затянется

запланируйте еще про оптимизации в похапе: low memory usage, high speed и т.д. и т.п. ощень актуально сейчас.. вот прям сейчас ^_^

сильно завязано на версию

крайняя

и нечего придумывать

и от версии к версии пхп ничего не гарантирует

как бы кто остался в 5ой - тот "молодец".. его проблемы

вообще я бы советовал http://www.phpinternalsbook.com/

полезно, благодарю

вообщем все равно рад замечаниям постараюсь учесть

любопытно: а какая цель у тебя?

моя личная научится излагать свои мысли перед людьми (и тут прогресс идет, если посмотреть мои первые видео и те что сейчас)

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

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

просто уменьшить количество говно программистов, сейчас огромное количество курсов типо программирование за 24 часа

после которых люди не совсем прогарммисты

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

на каждом стриме или видео освежаешь свои знания

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

Интересно, что быстрее для частичного совпадения? Регулярка или indexOf ?

В js

Элементов для сравнения около 25к

Думаю оставить indexOf хотя регуляркой, конечно, можно более сложное сравнение проделывать.

Интересно, что быстрее для частичного совпадения? Регулярка или indexOf ?

indexOf

Да, его и оставлю. Ибо там искать будут по номеру унп или названию... Городить огород, думаю, не нужно.

Тем более данные для сравнение в одном регистре ?

Не могу найти лучшие подходы для такой задачи: на моем сервере я проксирую запросы с историей на S3, сервер S3 может вернуть любой статус в случае неудачи, но я возвращаю 404 (ясно дело почему ! ?). Как быть со статусом с S3? Есть ли хороший подход, как его показывать (в каких нибудь headers или еще где)

Не могу найти лучшие подходы для такой задачи: на моем сервере я проксирую запросы с историей на S3, сервер S3 может вернуть любой статус в случае неудачи, но я возвращаю 404 (ясно дело почему ! ?). Как быть со статусом с S3? Есть ли хороший подход, как его показывать (в каких нибудь headers или еще где)

Либо подскажите, какой специалист сможет на этот вопрос ответить