Да, отлично

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

+1

это ты сейчас так заумно сказал "ифы в файнали недопустимы"? :)

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

Если там ифы будут из-за другой логики, то почему бы нет

какие ваши доказательства

Клянусь святым асинхронным генератором

асинхронные клятвы не принимаются, а то знаем вас... оставят вместо клятвы банальный promise и свялят

)))

Коллеги - как думаете стоит проводить DevConf в этом году? Что нового появилось с прошлой что хотелось бы узнать, обсудить и прочее?

не был ни на одной конфе, но: 1) невозможно разоравться между всеми залами, а послушать полезно всё 2) скучные доклады лично для меня сначала читают changelog, и статьи из wikipedia, потом приходит мастодонт и рассказывает как у них всего много (но не рассказывает про архитектуру) и обязательно начинается пиар фреймворка нужного 3,5 людям на планете. только не подумай что я говорю что всё говно и всё плохо, вы молодцы. ps открыл секцию по golang - там описания в разы интереснее - люди делятся реальными проблемами. pss лично мне понравился формат fwdays

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

+

Получается что интереснее компактные целевые митапы

Где 3-4 доклада по 20 минут

ну и работу еще искать, которая все эти конфы оплачивала, своего бабла жалко

С Питером может быть проблема - наберется мало народа где-то году в 2013 хотели устроить акцию РИТ шагает по стране

в москву банально добраться проще + количество компаний в мск больше

ну и работу еще искать, которая все эти конфы оплачивала, своего бабла жалко

о, у меня каждый 5й на собеседовании спрашивает про оплачиваемые конференции :)

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

добавлю, на конференцию сеньоры ходят послушать про архитектуру, опыт решения сложных проблем (для @confguru)

или просто выпить

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

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

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

да и действительно сложные внутренности не втиснуть в доклад...

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

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

Помню пару лет назад на девконфе выступал парень про то как прикручивать DDD к yii1, и перед докладом он объявил что его уволили :D

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

Может он даже в этом чате есть

ddd ваще срамные буквы ;) сразу отказ на собеседовании ;)

добавлю, на конференцию сеньоры ходят послушать про архитектуру, опыт решения сложных проблем (для @confguru)

спасибо

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

хабр читай ;)

Да там мало по пхп

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

спасибо

главное учитывать мое мнение слишком сильно - тк я 146% не заплачу за билет на devconf ближайшие 3 года

;)

и мое слишком сильно учитывайте ;)

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

для джунов был бы хороший доклад про использование SPL. а то спрашиваешь людей использовали - говорят нет. кстати про то как устроен composer был бы не плохой доклад

для джунов был бы хороший доклад про использование SPL. а то спрашиваешь людей использовали - говорят нет. кстати про то как устроен composer был бы не плохой доклад

А что в composer сложного? Пересказ мана?

А что в composer сложного? Пересказ мана?

внутренности вполне интересны, вот что происходит после composer install или new Foo

ман можно пересказать в формате: самые интересные грабли

вон @chebotarevp поднимал вопрос использования amphp на проде если я верно помню

когда все баги в проекте исправлены - наберите composer update для загрузки новых багов

да

ни одного доклада по асинхронности ваще =)

Хотя эта тема уже с 2015 года развивается

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

по сути с приходом php7, пхп может быть как нода

внутренности вполне интересны, вот что происходит после composer install или new Foo

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

не релоадь на горячую ;)

не так много причин горячего релоада

Докладчик про ДДД которого уволили - это Иван Матвеев :) и он сейчас в хорошей конторке работает

а уволил его григори? ;)

Подожди, он же тут писал вроде?

Помню даже аватарку его, в смокинге

а по тонкой настройке php-fpm было что нить толковое?

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

хотя рассказать можно было бы, но там доклада то на 15 минут

не релоадь на горячую ;)

Вот есть у меня допустим асинхронный движок воркера, который написан на пхп с компосером. И есть сами воркеры, который являются частью проекта. Они со своим компосером тоже, и когда движок инклюдит эти файлы воркеров, то могут возникнуть конфликты неймспейсов

главное учитывать мое мнение слишком сильно - тк я 146% не заплачу за билет на devconf ближайшие 3 года

и не плати, приезжай в качестве докладчика

можно упростить до "у меня есть два проекта со своими композерами, и я хочу из первого сделать инклуд второго". И сразу "шооооо?!" ;)

вообще для пхп воркеров асинхронный движок на пхп... это какой-то изврат... воркеры, то поди, как отдельный процесс каждый работают?

можно упростить до "у меня есть два проекта со своими композерами, и я хочу из первого сделать инклуд второго". И сразу "шооооо?!" ;)

Да именно так получается

вообще для пхп воркеров асинхронный движок на пхп... это какой-то изврат... воркеры, то поди, как отдельный процесс каждый работают?

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

в тредах?

ERROR: S client not available

Ну если что вычислительное попалось - можно тред или процесс породить, а так в одном треде все можно делать

Как нода и поступает

Короче што я распинаюсь, в раби уже такое вовсю реализовано https://github.com/mperham/sidekiq

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

вот офигенный пример, да ;) сделали из руби какой-то мультитул, и в итоге никому она не нужна

На ней работает гитлаб если я правильно помню

гитлаб? это тот, у которого мои пуши пары файлов по 20 секунд уходят и сохранение страницы в вики секунд 40?

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

У нас на прошлой работе очень была такая потребность - 5-6 проектов было, на каждом 3-5 воркеров работает. Письма рассылают, счетчики обновляют, рейтинги пересчитывают в базе и т.д. Это запускалось просто как 5 консольных команд например. Отмасштабировать это нельзя было, посмотреть статистику по выполняющимся задачам - тоже, следить за падающими демонами нужно.

а потом девопс носится по офису с матерными воплями

Не утрируй, у нас было все нормально ;) Мы сами там и девопсили и код писали и носились с воплями.

пффф... следить за твоим супер-пупер асинхронным мультитулом не нужно?

пффф... следить за твоим супер-пупер асинхронным мультитулом не нужно?

Если это как опенсорс проект который постоянно допиливается - то не нужно, он кучу работы на себя берет.

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

в опенсорсе демоны не падают! ;)

В семерке - не падают ;)

Можно отловить любой throwable

аааха ;) таже out of memory?

Да это забарывается ловко

ну да... достаточно лишь сразу писать идеальный код, и все ;)

Один легковесный процесс-контроллер порождает второй процесс с воркерами, сам не жрет память и следит за ними

Если надо еще воркеров порождает, зависшие убивает, релоадит и все остальное

с тредами? ;)

с процессами. У них разные пространства памяти.

и каждый процесс в event loop и выполняет разные задачи?

Да там насколько хватит фантазии придумать

Может одну блокирующую задачу, может несколько асинхронно. Это уже дело техники.

не надо фантазии, нужно архитектуру под задачи строить, а не задачи под архитектуру

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

По умолчанию можно сажать каждый воркер в свой процесс и пусть он работает синхронно в один тред.

да просто у тебя фантазия приведет к невменяемому коду. "Может одну блокирующую задачу, может несколько асинхронно. " - вот как это? У тебя 10 воркеров, как ты поймешь, что у тебя 5-й воркер занят блокирующей задачей, и, хотя сейчас по rr его очередь, нужно его пропустить?

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