твоя проблема в том, что ты не различаешь сам язык и апи к этому языку (в понятиях пхп - sapi)

раз фиксят - умирало ?‍♂️

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

тащемта, на пхп даже синхронизировать процессы можно. Но надо ли это

как по мне - це изврат

Мое доверие к демонам на пхп - на уровне "воркер запустился, отработал, умер"

ты просто не умеешь их готовить)

ну конечно

с таким подходом и го так же можно юзать)

ты просто не умеешь их готовить)

с таким подходом можно говорить про что угодно

ну так-то у меня всё на демонах) живёт себе, дела делает)

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

cli-аппка !== демон)

ну так-то у меня всё на демонах) живёт себе, дела делает)

на пхп?

на пхп?

в числе прочего

ну так-то у меня всё на демонах) живёт себе, дела делает)

ммм, кайф то какой)

cli-аппка !== демон)

лол, по времени работы композера иногда - почти демон

ммм, кайф то какой)

да нормально) 0 проблем

лол, по времени работы композера иногда - почти демон

так то это странный аргумент)

да нормально) 0 проблем

ну конечно, simple & flexible в действии ?

так то это странный аргумент)

я тебе о том, что пхп - это не только про реквест-респонс

да, его создавали таковым изначально

знаете, так то и на асм игры пишут

ну конечно, simple & flexible в действии ?

ну я могу поднять ещё 2 десятка пхпшных демонов, и система будет нормально работать, как единое целое)

я бы не назвал это здоровым программированием

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

и сказали "а пхп вполне себе общего назначения"

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

я тебе о том, что пхп - это не только про реквест-респонс

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

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

да я вообще ни капли не апологет пихания пхп во все дыры

так-то и го во все дыры не воткнёшь)

и язык под названием Х тоже)

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

продолжайте сами

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

а то, что думает там какой-то программист освоивший го ... в общем пофиг ;)

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

я нашего гошника готов в окно выбросить, например

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

кто все?

я нашего гошника готов в окно выбросить, например

смотри, чтоб у него там горутина не зависла в слипе

смотри, чтоб у него там горутина не зависла в слипе

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

!($a instanceof stdClass) или (!$a instanceof stdClass) как правильно писать

instanceof приоритет выше, чем !, так что оба варианта валидны

!($a instanceof stdClass) или (!$a instanceof stdClass) как правильно писать

Это вопрос, уровня доки. RTFM http://php.net/manual/ru/language.operators.precedence.php

но лично я хреначу скобочки

Это вопрос, уровня доки. RTFM http://php.net/manual/ru/language.operators.precedence.php

cпасибо, почитал

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

мне кажется не оч

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

"рантаймить", "вырубать"... че?

лучше тебе не знать :D

я уже все придумал

я уже все придумал

приходи ещё)

кто все?

на хабре том же почитал, что разные варианты есть написания ТЗ, но у нас типо по ГОСТ любят, да и в интернете много примеров где все по ГОСТ

на хабре том же почитал, что разные варианты есть написания ТЗ, но у нас типо по ГОСТ любят, да и в интернете много примеров где все по ГОСТ

ну то есть из 100% всех мы берем 1% тех кто верят в ТЗ

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

ТЗ хорошо... а хорошее ТЗ - еще лучше! ;)

Сергей, ты с бюджетниками работал когда-нитбудь? В смысле, не с государством, а с любыми организациями, у которых есть понятие "фиксированный бюджет".

да, конечно

ну и о каком "дроблении" может идти речь, если у тебя есть фиксированный бюджет, и фиксированный функционал, который нужно получить?

ну и о каком "дроблении" может идти речь, если у тебя есть фиксированный бюджет, и фиксированный функционал, который нужно получить?

к тебе приходит чел и говорит "хочу 10 фич за N денег" а ты ему "не ну 10 фич этих будут стоит M денег где M ~= 2*N" Что мне как клиенту делать?

у бюджетников не так все же

в начале они приходят и говорят нам надо такую фигню

договариваться о 5 фичах вместо 10..и потом писать на это ТЗ ;)

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

потом после нг до весны они выбивают бюджет под существующее тз

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

Проект весь разбил по блокам и задачам

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

их там миллион

весной они согласовали бюджет и к лету им падает N денег

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

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

как деньги упали объявляют тендеры и прочие приседания

договариваться о 5 фичах вместо 10..и потом писать на это ТЗ ;)

но бюджет у тебя по времени, а не по фичам, а значит в целом ты можешь сам назначить себе фиксированный бюджет скажем на 2-4 недели и на это сделать ТЗ. А дальше все строится по принципу выстраивания доверительных отношений между клиентом и заказчиком. И да в 90% случаев заказчик с фиксированным бюджетом никак не заинтересован в продкуте (какой-то менеджер которому сверху кто-то сказал) или исполнителя беспокоит больше как выжать побольше бабла. Из-за этого доверительных отношений нет. А еще ТЗ и коммитменты по бюджету и сроку это хорошая стратегия для заказчика спихнуть ответственность на разработчика.

а еще я не помню ни одного проекта где бы ТЗ не поменялся по итогу и не приходилось вести переговоры о изменении скоупа работ и переоценке

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

ТЗ тут только как простой способ сместить ответственность.

а да - еще реже я видел клиентов которые подписывались под ТЗ но при этом вдумчиво его читают.

> но бюджет у тебя по времени, а не по фичам да здрасти... бюдет по фичам и времени, причем фича первостепенна, ибо она оценивается во времени и идет в приложение > И да в 90% случаев заказчик с фиксированным бюджетом никак не заинтересован в продкуте Это не правда... юношеский максимализм "все попилим". 90% с кем я общался - хотят получить хороший продукт

а еще я не помню ни одного проекта где бы ТЗ не поменялся по итогу и не приходилось вести переговоры о изменении скоупа работ и переоценке

это так, но тут гдавное, что ТЗ есть, т.е. есть что менять и есть, с чем идти в суд в случае чего твои рассуждения о том, что "ну мы не знали сначала" суд не примет

и то, что в 95% случаев ТЗ - профанация, не значит, что нельзя написать хорошее ТЗ ;)

> но бюджет у тебя по времени, а не по фичам да здрасти... бюдет по фичам и времени, причем фича первостепенна, ибо она оценивается во времени и идет в приложение > И да в 90% случаев заказчик с фиксированным бюджетом никак не заинтересован в продкуте Это не правда... юношеский максимализм "все попилим". 90% с кем я общался - хотят получить хороший продукт

хз кто там чего про максимализм, я про 6 лет работы в аутсорсе на большие компании) о довольно редко попадались стэкхолдеры которым было не плевать. Обычно не плевать кому-то кто выше. Смысл в том что большинство представителей клиентов с которыми я сталкивался были лишь представителями, доступа к другим стэкхолдерам напрямую почти никогда небыло. Тут еще важен регион. Скажем в скандинавии все было проще и лучше, в штатах более-менее последние года 2-3, в европпе 50/50.

это так, но тут гдавное, что ТЗ есть, т.е. есть что менять и есть, с чем идти в суд в случае чего твои рассуждения о том, что "ну мы не знали сначала" суд не примет

ТЗ/спецификация проекта должна быть, где-то должно быть зафиксировано как это все работает. Другой момент что оно не должно быть все и сразу и может развиваться

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

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

т.е. времени - фикс

ты можешь разделить один фиксированный бюджет на несколько фиксированных бюджетов?

и еще момент - ты можешь раздробить и приоритизировать фичи?

и исходя из них подписаться на 5 обязательных и 5 было бы неплохо?

уже риски меньше. понятно что платить за неизвестно какой процент функционала никто не будет

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

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

А кто его эстимейтил?

исполнитель

ну тут зависит от размера фиксированного бюджета. Одно дело когда бюджет в $50K каких и другое дело когда речь идет о $1m+

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

да никак не зависит ;) зависит только от заложенной прокладки "на всякий случай"... а она зависит от качества ТЗ, к слову

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

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

и да, там мы составляли что-то типа более подробного ТЗ но оно на сам тендер не сильно влияло. А еще занятный факт что продукт менеджер со стороны клиента сменился через 3 месяца после старта разработки и оказалось что предыдущий менеджер был пиздабол и нифига не читал а просто говорил "да".

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