угу

актуальна ли еще? 2010 год. "MySQL. Оптимизация производительности" https://www.ozon.ru/context/detail/id/6573935/

и какие схемы используются для распределения нагрузки в 2018 году (балансировщики, сервера БД master/slave, веб сервера, облако). Комбинаций сколько угодно может быть и на разных уровнях, какая схема популярная?

и какие схемы используются для распределения нагрузки в 2018 году (балансировщики, сервера БД master/slave, веб сервера, облако). Комбинаций сколько угодно может быть и на разных уровнях, какая схема популярная?

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

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

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

так что думаю тебе стоит пока почитать книжку которую ты сам и скинул и малиться что тебе ближайшие 2-3 года не придется работать с терабайтными базами распределенными

ну мол тебе надо сча простые штуки, про идексы, про селективность, про нормализацию/денормализацию/jsonb.... ну и рассмореть вариант заюзать нормальную СУБД (постгрес например)

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

шоб знать

так что думаю тебе стоит пока почитать книжку которую ты сам и скинул и малиться что тебе ближайшие 2-3 года не придется работать с терабайтными базами распределенными

я ее читал и так же благополучно забыл)

бесит это, новое изучаешь, старое забываешь

ну такое... может оно тебе не надо просто?)

месяц покатушек на велике по полям по лесам, походы с палатками, а после садишься за комп и такое чувство как в первый раз сел

месяц покатушек на велике по полям по лесам, походы с палатками, а после садишься за комп и такое чувство как в первый раз сел

ты там чатики мне написал? великий оптимизатор?)

ну такое... может оно тебе не надо просто?)

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

какие чатики?

какие чатики?

может я спутал... ладно забей

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

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

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

Так-то да

а есть для нашего рынка такая же карта? https://github.com/kamranahmedse/developer-roadmap

или та актуальна и для нас?

для кого нас?

для рынка снг

нет, рынок СНГ это битрикс и магенту. Сам то как думаешь?

да какой битрикс, 1-2 вакансии из 9 yii

ну и так себе роадмэп... роадмэп похапешника

restul api, learn nosql (при уровне детализации devops стафа даже грустно)

RabbitMQ of kafka... как будто бы они эквивалентны

запили свою роадмап, я тебе звездочку на гитхаб поставлю)))

зачем?)

список технологий для веб-дева бекенда

а так спросят тут что учить, а ты такой ссылку кидаешь, хоба

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

а толку нету

потому что ссылочку на coupling/cohesion пропустят зато пару вечеров на orientdb потратят конечно

или на какую-нибудь хипстерскую херню другую

Ребят, подскажите, если с нашей системой взаимодействуют 10 клиентов, действие они совершают одно и то же (например активация продукта), но параметры запроса могут быть разными, валидация разная, реакция на события тоже разная, и некоторая логика активации тоже отличается, стоит ли делать один контроллер на всех или все же стоит сделать для каждого клиента свой контроллер?

Я бы сделал один, но использовал паттерн Стратегия. На основе логина клиента (или какого-то другого критерия) выбирал бы нужный класс, который описывает логику обработки запроса для этого клиента

ребчт, какой домен приятнее, с дефисом или без? gameslab net games-lab net

ребчт, какой домен приятнее, с дефисом или без? gameslab net games-lab net

без

дефис это всегда неудобно в домене

доставать до линии цифр

а если речь не трогает клавиатуру

визуально, как лучщ?

и визуально тоже без

Я бы сделал один, но использовал паттерн Стратегия. На основе логина клиента (или какого-то другого критерия) выбирал бы нужный класс, который описывает логику обработки запроса для этого клиента

у нас клиент выбирается по поддомену. То есть у нас будет какой то один класс для клиента, который будет все знать? валидацию, какие параметры обрабатывать, как реагировать на события, будет знать настройки клиента и логику действий?

Нет, не один. Раздели это на классы: запрос, валидатор, обработчик событий, ещё что-то. Заведи интерфейсы для этих классов и реализуй их для каждого клиента

Нет, не один. Раздели это на классы: запрос, валидатор, обработчик событий, ещё что-то. Заведи интерфейсы для этих классов и реализуй их для каждого клиента

у нас используется laravel, допустим в контроллере используем ValidatorInterface, как с помощью di решить, какой именно класс должен создаться? Зависимости и привязки ведь компилятся и кэшируются, то есть нам до запроса еще нужно определить все зависимости. Как мне казалось, влезать в контейнер и подгружать зависимости (сервис провайдер) на уровне middleware или того же конструктора контроллера как то не правильно, нет?

Можно в описании контейнера написать, что для вот этого контроллера ValidatorInterface нужно подготовить через фабрику, которая уже будет знать про то, как выбрать нужный валидатор.

Можно в описании контейнера написать, что для вот этого контроллера ValidatorInterface нужно подготовить через фабрику, которая уже будет знать про то, как выбрать нужный валидатор.

о, точно, спасибо большое!) попробую реализовать

private функции в контролере допустимы? или єто звоночек что чтото делаю не так и нужно пересмотреть логику

Скорее всего

private функции в контролере допустимы? или єто звоночек что чтото делаю не так и нужно пересмотреть логику

Вот как ты считаешь, кто вызывает эти методы твоего контроллера?

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

будем мигрировать на Team Foundation Server

Это ведь тоже продукт микромягких

Это ведь тоже продукт микромягких

у меня проблемы с юмором, листай дальше)

private функции в контролере допустимы? или єто звоночек что чтото делаю не так и нужно пересмотреть логику

допустимы, но подумай как можно их убрать в сервисы например. Есть ли профит. Или это тупой бойлерплейт - почему он нуже только в одном контроллере?

у меня проблемы с юмором, листай дальше)

Понял)

ясно, всем спс

Гайз Хочу оптимизировать код под php 7.2 Что выпиливать кроме array() на [] и count($array)>0 на !empty($array)

херасе оптимизация... можешь ещё двойные ковычки на одинарные поменять)

и проверки на null, они ведь очень тяжелые

и проверки на null, они ведь очень тяжелые

тяжелее каунта?)

и проверки на null, они ведь очень тяжелые

Выключи сарказм)

без сарказма жить грустно

Выключи сарказм)

да я в слезах по пояс

да я в слезах по пояс

сверху или снизу?

Гайз Хочу оптимизировать код под php 7.2 Что выпиливать кроме array() на [] и count($array)>0 на !empty($array)

у тебя phpstorm?

сверху или снизу?

пофиг)

тулзы для статического анализа имеют профили по зачистке депрекейтов и оптимизациям

Гайз Хочу оптимизировать код под php 7.2 Что выпиливать кроме array() на [] и count($array)>0 на !empty($array)

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

а теперь серьезно: массивы - пофиг, empty - хз, но вроде тоже ничего не несет

у тебя phpstorm?

+

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

да там слово оптимизация в целом рядом не стоит) просто по сути вопроса

Гайз Хочу оптимизировать код под php 7.2 Что выпиливать кроме array() на [] и count($array)>0 на !empty($array)

я конечно не видел проекта, но есть мнение что ты просто потратишь время зря

а теперь серьезно: массивы - пофиг, empty - хз, но вроде тоже ничего не несет

разницы не будет, массив же пустой. А длина массива вроде как просто хранится

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

да там слово оптимизация в целом рядом не стоит) просто по сути вопроса

и 7.2 тоже

и если у тебя там нет графов данных по 100K нод то в целом вообще плевать

[] от array отличается только кол-вом символов, count - конструкция, которая выводит то, что уже давно известно...

Гайз Хочу оптимизировать код под php 7.2 Что выпиливать кроме array() на [] и count($array)>0 на !empty($array)

opcache ты уже подключил?

Да, суть вопроса остаётся Я просто примеры привёл

Да, суть вопроса остаётся Я просто примеры привёл

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

какую цель ты приследуешь?

начни короч с php-cs-fixer

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

что до оптимизаций - берешь профайлер и смотришь узкие места

то что ты описал называется "мне просто скучно и нечем заняться"

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

ну или в промежуточных версиях между твоей и 7.2

начни короч с php-cs-fixer

Читаю, спасибо

/** @var null|array|bool $rows**/ и чем !empty($rows) лучше, чем true === \is_array($rows) && 0 !== \count($rows) ?)

по мне так хуже

в смысле empty хуже явных проверок