Стоило также упомянуть про утилиту *cachegrind. Я пользуюсь qcachegrind на маке, причем полезен как вариант с открытием файла в шторме, так и построением визуальной картины происходящего в qcachegrind. Насколько мне известно, для линукса утилита называется kcachegrind, а q* это лишь порт для мака, впрочем, мне не так это важно, утилита хорошая и полезная.
Как вариант, при первой загрузке можно в очередь кидать задачу на ресайз, а возвращать обычное большое изображение, чтобы пользователя не заставлять ждать
Работая тимлидом в текущий момент, не могу не согласиться с большинством пунктов статьи, но хочу от себя дополнить несколькими тезисами, которые для себя сам вывел:
нельзя ставить себя выше команды - тимлид без команды никто, а вот команда без тимлида вполне может существовать; фактически, тимлид подчиняется команде в некоторых смыслах, да, он по-прежнему несет за нее ответственность, но действовать он должен на балансе интересов команды и бизнеса, а не на основе интересов бизнеса и своих собственных
самый удачный вариант тимлида - выбранный командой, поскольку это будет означать, что доверие команды нужно только оправдывать, но не строить его с нуля, как в случае с приглашенным со стороны тимлидом; плюс, тимлид, выбранный из уже существующих участников коллектива, априори более погружен в проблемы продукта, и может принять более взвешенное решение
last, but not least - хорошего тимлида не должно быть видно, как и хорошего сисадмина (в старых терминах); задача тимлида - настроить все так, как удобно команде и бизнесу, а далее лишь держать руку на пульсе, а команда в случае вопросов обратится сама, поскольку доверяет экспертизе и взвешенности решений выбранного тимлида (как вариант, в освободившееся время можно заниматься разработкой или чем-то другим, в зависимости от хард скилов самого тимлида)
Все вышеперечисленное - мое личное мнение, не пытаюсь никому его навязывать :)
В соседнем комментарии как раз ответил. Возможно, мне стоило уточнить, что мой комментарий относился к бизнес-слою приложения, а не к валидации реквестов, например. Пожалуй в валидаторах или ассертах действительно это имеет право на жизнь.
В go не силен, писал пару мелких сервисов для себя, но глубоко не погружался, не могу ответить.
Насчет того, что isLegalAge должен внутри вызывать isPositiveInt — это выглядит как ненужное усложнение, как по мне — это самостоятельная реализация. А если нужны именно проверки на позитивность, то пожалуй да, оно так и должно выглядеть.
Если мы говорим об абстрактных валидаторах, которые не знают, что в них приходит (например, а-ля валидация ларавеля), то mixed и объединения типов кажутся хорошим вариантом. Но если говорить о бизнес-логике, имхо она должна быть конкретной, и в этом случае mixed уже выглядит как костыль для ослабления для каких-то кейсов, сходу так и не придумаешь даже.
Если вы «играете в типизацию», то необходимость реализовывать такой код говорит о неверной архитектуре проекта. Если вам нужно проверить, положительный ли баланс на карте клиента, то очевидно это будет `isPositive(float $balance)`. И напротив, если вам нужно проверить, совершеннолетний ли человек, то это будет `isLegalAge(int $age)`. А все остальное — плохая архитектура. ИМХО.
Мы в компании рассматривали и то, и другое, в итоге действительно остановились на swarm, как на более прозрачном решении (разбирались с коллегой с нуля, опыта девопса почти не было).
В нашем понимании, k8s больше подходит для сервисов, которые можно закинуть куда-то в облака и двигать ползунки масштабирования, оценивая, как растут графики и утекают денежки из кошелька.
В нашем же случае мы уперлись в бутылочное горлышко в плане mysql, с которым не очень понятно, как его масштабировать в рамках контейнеров (у нас нагрузка пока не очень большая, и мы пока даже не реплицировали базу в ридонли реплики, но думаем над этим).
В итоге мы остановились на трех хороших серваках, над которыми поднят swarm, настроено много реплик api-сервисов / фронтендов, а базы один-единственный контейнер (с пробросом файлов на хост для надежности) и вполне себе справляется.
Возможно в дальнейшем при росте нагрузки мы будем рассматривать партицирование, и тогда наверное уже будем как-то вновь смотреть в сторону k8s. А пока что наш выбор — swarm.
Ну и swarm очень хорошо получилось подружить с teamcity. Все собирается автоматом, тестируется и с нулевым даунтаймом выгружается, без головной боли.
github.com/yiisoft/yii2/issues/9903 а вот эту штуку поправите? Видел там метки 2.1… А то уже несколько раз про нее забывал в своих миграциях и долго вспоминал, что же там не так :(
Мы смотрим на эту php-функцию filterUsersByAge и сходу не понимаем, массив чего нам пришел. Что именно за array? В java можно было бы написать List<User>, и мы бы понимали, что к нам пришел список объектов User. Или Set<User>, и мы бы сразу видели, что это список без повторов, т.е. только разные объекты.
Вообще-то можно написать function someAction(User ...$listOfUsers) и вызывать ее someAction(...$users), в плане тайпхинтинга это удобно. Имхо, конечно.
Не знаю, что Вам не понравилось / не удалось в связке Win10 + вся удобная среда разработки + WSL.
Мое утро (иногда день, вечер или ночь) начинается так: запускается винда, запускается PhpStorm, DataGrip, прочие мелочи для удобной жизни, дальше запускается WSL, вводится команда ./start.sh, и поехали.
sudo service postgresql start
sudo service redis-server start
sudo service elasticsearch start
sudo service gearman-job-server start
sudo service rabbitmq-server start
sudo service php7.1-fpm start
sudo service supervisor start
sudo service nginx start
(да-да, мне все еще иногда бывает нужен gearman)
все пакеты php и nginx работают из коробки человека с ником ondrej
все проекты находятся в своих папках где они обычно лежат в винде: C:\Users\...\PhpStormProjects\MyProject, доступ к ним легко получается по алиасу /mnt/c/Users/.../PhpStormProjects/MyProject. Единственное условие, чтобы юзернейм виндового юзера был латинницей (не знаю, может уже пофиксили), либо класть проекты в папку "не по умолчанию".
Поскольку WSL и все-все-все работает локально и используется мной для целей разработки/тестирования, мне не нужно заморачиваться насчет прав доступа, мой юзер WSL добавлен в sudoers и в группу root. Вебсервер и прочее заводится с полпинка и ни на что не жалуется. В хосты прописываем что-то вроде myproject.local 127.0.0.1 и вуаля, радуемся жизни.
Если кому-то интересно, могу запилить подробное описание всего процесса настройки, но я думаю из здесь присутствующих это вряд ли кому-то будет интересно, ибо все и так уже все умеют.
Если будете еще раз ставить систему с нуля — рекомендую (но это лично моя рекомендация, не ручаюсь за то, что это лекарство от всех проблем) ставить английскую версию.
Во-первых, в русской версии некоторые модули (например, Кортана) успешно вырублены на довольно глубоком уровне, и некоторые проблемы ранних обновлений точно были с этим связаны (именно поэтому, например, Anniversary Update доходила до RU-сборок чуть дольше, чем была основная волна обновления), а во-вторых англоговорящий саппорт, хоть и индусский (одну из моих проблем поочередно решали три индуса), но не такой жадный и явно более обученный.
В вышеупомянутом случае все трое подключались к моей машине и делали какую-то странную магию с редактированием реестра, я даже не успевал записывать, что и куда они вводят, но проблему они, к своей чести, в итоге решили (была проблема с выбором темпа получений insider-билдов).
(Если не считать того, что всё за тебя уже настроено заранее)
sudo apt install php php-common php-mysql mysql apache2
Базовый веб-сервер, не особо заморачиваясь со всякими http/2, rabbitmq, zabbix и прочими фенечками, устанавливается на VPS минут за 15, 10 из которых вы будете пить чай.
Я вижу шаред-хостинги только как площадку для какого-то самопального блога на вордпрессе от человека, который немножко перерос простые html странички, но не хочет изучать программирование.
Стоило также упомянуть про утилиту *cachegrind. Я пользуюсь qcachegrind на маке, причем полезен как вариант с открытием файла в шторме, так и построением визуальной картины происходящего в qcachegrind. Насколько мне известно, для линукса утилита называется kcachegrind, а q* это лишь порт для мака, впрочем, мне не так это важно, утилита хорошая и полезная.
А никого не смущает, что после слов
сразу же идет решение, которое начинается с:
т.е. с использования дополнительного пространства?
Или я что-то не знаю про программирование?
Как вариант, при первой загрузке можно в очередь кидать задачу на ресайз, а возвращать обычное большое изображение, чтобы пользователя не заставлять ждать
Работая тимлидом в текущий момент, не могу не согласиться с большинством пунктов статьи, но хочу от себя дополнить несколькими тезисами, которые для себя сам вывел:
нельзя ставить себя выше команды - тимлид без команды никто, а вот команда без тимлида вполне может существовать; фактически, тимлид подчиняется команде в некоторых смыслах, да, он по-прежнему несет за нее ответственность, но действовать он должен на балансе интересов команды и бизнеса, а не на основе интересов бизнеса и своих собственных
самый удачный вариант тимлида - выбранный командой, поскольку это будет означать, что доверие команды нужно только оправдывать, но не строить его с нуля, как в случае с приглашенным со стороны тимлидом; плюс, тимлид, выбранный из уже существующих участников коллектива, априори более погружен в проблемы продукта, и может принять более взвешенное решение
last, but not least - хорошего тимлида не должно быть видно, как и хорошего сисадмина (в старых терминах); задача тимлида - настроить все так, как удобно команде и бизнесу, а далее лишь держать руку на пульсе, а команда в случае вопросов обратится сама, поскольку доверяет экспертизе и взвешенности решений выбранного тимлида (как вариант, в освободившееся время можно заниматься разработкой или чем-то другим, в зависимости от хард скилов самого тимлида)
Все вышеперечисленное - мое личное мнение, не пытаюсь никому его навязывать :)
Всем хороших команд и тимлидов)
Насчет того, что isLegalAge должен внутри вызывать isPositiveInt — это выглядит как ненужное усложнение, как по мне — это самостоятельная реализация. А если нужны именно проверки на позитивность, то пожалуй да, оно так и должно выглядеть.
Если мы говорим об абстрактных валидаторах, которые не знают, что в них приходит (например, а-ля валидация ларавеля), то mixed и объединения типов кажутся хорошим вариантом. Но если говорить о бизнес-логике, имхо она должна быть конкретной, и в этом случае mixed уже выглядит как костыль для ослабления для каких-то кейсов, сходу так и не придумаешь даже.
В нашем понимании, k8s больше подходит для сервисов, которые можно закинуть куда-то в облака и двигать ползунки масштабирования, оценивая, как растут графики и утекают денежки из кошелька.
В нашем же случае мы уперлись в бутылочное горлышко в плане mysql, с которым не очень понятно, как его масштабировать в рамках контейнеров (у нас нагрузка пока не очень большая, и мы пока даже не реплицировали базу в ридонли реплики, но думаем над этим).
В итоге мы остановились на трех хороших серваках, над которыми поднят swarm, настроено много реплик api-сервисов / фронтендов, а базы один-единственный контейнер (с пробросом файлов на хост для надежности) и вполне себе справляется.
Возможно в дальнейшем при росте нагрузки мы будем рассматривать партицирование, и тогда наверное уже будем как-то вновь смотреть в сторону k8s. А пока что наш выбор — swarm.
Ну и swarm очень хорошо получилось подружить с teamcity. Все собирается автоматом, тестируется и с нулевым даунтаймом выгружается, без головной боли.
Вообще-то можно написать function someAction(User ...$listOfUsers) и вызывать ее someAction(...$users), в плане тайпхинтинга это удобно. Имхо, конечно.
Не знаю, что Вам не понравилось / не удалось в связке Win10 + вся удобная среда разработки + WSL.
Мое утро (иногда день, вечер или ночь) начинается так: запускается винда, запускается PhpStorm, DataGrip, прочие мелочи для удобной жизни, дальше запускается WSL, вводится команда ./start.sh, и поехали.
(да-да, мне все еще иногда бывает нужен gearman)
все пакеты php и nginx работают из коробки человека с ником ondrej
все проекты находятся в своих папках где они обычно лежат в винде:
C:\Users\...\PhpStormProjects\MyProject, доступ к ним легко получается по алиасу/mnt/c/Users/.../PhpStormProjects/MyProject. Единственное условие, чтобы юзернейм виндового юзера был латинницей (не знаю, может уже пофиксили), либо класть проекты в папку "не по умолчанию".Поскольку WSL и все-все-все работает локально и используется мной для целей разработки/тестирования, мне не нужно заморачиваться насчет прав доступа, мой юзер WSL добавлен в sudoers и в группу root. Вебсервер и прочее заводится с полпинка и ни на что не жалуется. В хосты прописываем что-то вроде
myproject.local 127.0.0.1и вуаля, радуемся жизни.Если кому-то интересно, могу запилить подробное описание всего процесса настройки, но я думаю из здесь присутствующих это вряд ли кому-то будет интересно, ибо все и так уже все умеют.
Во-первых, в русской версии некоторые модули (например, Кортана) успешно вырублены на довольно глубоком уровне, и некоторые проблемы ранних обновлений точно были с этим связаны (именно поэтому, например, Anniversary Update доходила до RU-сборок чуть дольше, чем была основная волна обновления), а во-вторых англоговорящий саппорт, хоть и индусский (одну из моих проблем поочередно решали три индуса), но не такой жадный и явно более обученный.
В вышеупомянутом случае все трое подключались к моей машине и делали какую-то странную магию с редактированием реестра, я даже не успевал записывать, что и куда они вводят, но проблему они, к своей чести, в итоге решили (была проблема с выбором темпа получений insider-билдов).
sudo apt install php php-common php-mysql mysql apache2
Базовый веб-сервер, не особо заморачиваясь со всякими http/2, rabbitmq, zabbix и прочими фенечками, устанавливается на VPS минут за 15, 10 из которых вы будете пить чай.
Я вижу шаред-хостинги только как площадку для какого-то самопального блога на вордпрессе от человека, который немножко перерос простые html странички, но не хочет изучать программирование.