А всякие построители форм плюс процессные движки - не low code. Хоть там и не пишут как бы код, а мышкой двигают, все же это специализированный инструмент, для которого нужно специалисты. Да, заточеность инструмента под конкретный домен, в некоторых случаях ускоряет разработку.
зы
конечно, апологеты "low-code" платформ с этим яростно несогласны ;). ну да бог им судья.
чтобы было понятнее, зачем появился новый cvs, почитайте про страдания fb с гитом, какие у них были с ним проблемы, как их пытались обойти. история легко гуглится.
похоже в fb решили таки решить проблему на корню.
зы
скажем прямо, проблемы fb с гитом не будут возникать у 99.9.. (тут еще некоторое количество 9) % разработчиков.
Допустим я, как-то озадачился, и посчитал свой доход за 10 лет. Потом сравнил с тем, "а что я сейчас имею", очень удивился, что доход утек в самых разных направлениях, активов почти не было. Но куда утек - точно сказать не мог. Вроде бы не кутил, но серьезная сумма дохода ушла в никуда.
Понял что с этим что-то надо делать, и начал вести учет расходов и доходов. 1-й шаг - оптимизировать расходы, все что не соответствует моим целям - безжалостно режется. 2-й шаг - дальше оптимизируем расходы - все ли расходы оптимальны? соответственно в первую очередь обращаем внимание на большие расходные статьи. 3-й шаг - оптимизируем доходы. с ними сложнее, при наемной работе. вначале копишь на депозите. потом ищешь куда можно вложиться. потом считаешь доходы/риски, балансируешь. повторяешь циклы.
И так шаг за шагом, увеличиваешь доходы от неосновной деятельности.
Сейчас уже прошло много лет с того момента, как я начал вести детальный учет расходов. Но продолжаю это делать. Процесс контроля расходов уже устаканился, но раз в полгода, раз в год, сажусь и анализирую что поменялось, хорошо ли это, или плохо, нужно ли корректировать, или наоборот усилить. Да и сам процесс регистрации событий по расходам стал рутиной, отнимает 2-3 минуты в день.
Зачем категории расходов? Очевидно, чтобы ими управлять.
Например, у меня появилась отдельная категория - Здоровье. И расходы по ней у меня не расходы, а инвестиция. Или расходы на образование (мое личное). Это тоже инвестиция. Дальше на большом периоде смотрю, приносит ли инвестиция доходы. Если не приносит, то почему, что нужно поменять. Ну и т.д.
И как итог, за время ведения учета, мои доходы и активы серьезно выросли. Расходы тоже выросли, но меньше. Серьезно поменялось мировоззрение. Вроде бы очевидные вещи, типа без инвестиций не будет дохода, наконец стали не просто теорией, а рутинной практикой. Направления профессионального роста выбираю в том числе и с учетом отношения доходы/усилия. В общем когда есть реальные цифры на руках, принимать правильные решения становится тривиальной задачей.
ок, чтобы знать на будущее, как называется ситуация, когда у нас есть ограниченный ресурс (отсутствует бюджет на расширение мощностей, либо это произойдет в будущем) и нам необходимо сегодня с этим ресурсом эффективно взаимодействовать. если это не экономия ресурсов, то что?
вы вот так одним махом перечеркнули reactive-благодетели, такие как circuit breaking, throttling
понятно что reactive рожден для решения проблемы максимальной утилизации cpu для многопоточных приложений, но часть фишек reactive достаются бесплатно. и зачем от них отказываться.
вот есть у нас ограниченный по мощности сервис, он может принимать не более 5 одновременных запросов. если уже сидите на reactive фреймворке, то задача решается элементарно через созданием отдельного scheduler'а. и из коробки у вас есть и ограничение на одновременные запросы, и обработка ошибок при превышении лимитов, и удобный рычаг, который можно крутить в большую или меньшую сторону для управления нагрузкой.
как в случае:
это();
то();
управлять лимитами, мне не очевидно. но наверно тоже можно. мой комментарий был про эту неочевидность.
К сожалению, почти сразу после подписания электронная подпись на документе – «протухает» и становится проблематичным доказать, что подпись была сделана при действующем сертификате. Как это ни печально: подпись вроде как есть, но срок окончания действительности сертификата истек, и «карета» на глазах превратилась в «тыкву», т.е. проверить подпись с истекшим сроком сертификата – это большая проблема.
OCSP-квитанция. Если ее прикладывать к каждой подписи, это решает проблему ответа на вопрос, а был ли сертификат действительным на момент подписания.
таск трекеры не панацея, а перекладывание ответственности на заявителя.
даже в шаблонами.
допустим я не шарю с сетевых делах. если при заполнении заявки у меня будут спрашивать про гейтвеи, транки, косы, квоты и т.д. я ничего вразумительного не заполню, даже если начну читать про все эти гейтвеи, транки, косы, квоты и т.д.
ну справедливости ради, реактивщина используется для экономии ресурсов, а под ресурсами может быть не только треды, но и что угодно - сетевые пулы, файловые пулы и т.д.
Devops - это не про ansible, gitlab, terraform, helm, etc. Технологии вообще не причем.
Devops - про взаимодействие условных девелоперов с условными админами для достижения общих целей. Если идет такой диалог, как в прологе статьи, это не devops. Это яркий пример той проблемы, которая присутствовала в прошлом, и присутствует в настоящем - отсутствие тесного взаимопонимания. И devops как раз вариант решения этой проблемы. Опять же решение не в технологиях, а в том, чтобы условный девелопер и условный админ стали одной командой с единой целью и начали друг с другом конструктивно обсуждать имеющиеся проблемы и возможные решения. И после принятия решения - имплементация может быть в использовании конкретной технологии.
Аналогичная история с Agile. Agile не про спринты, дейлики, ретро и прочее. Agile про тесное взаимопонимание бизнеса и технарей.
представляет реальную угрозу или мнимую, неважно.
важно, что движуха началась, а значит конкуренция, а значит больше потенциальной пользы для пользователей
Low code - это Excel, G Spreadsheets, и т.д.
А всякие построители форм плюс процессные движки - не low code. Хоть там и не пишут как бы код, а мышкой двигают, все же это специализированный инструмент, для которого нужно специалисты. Да, заточеность инструмента под конкретный домен, в некоторых случаях ускоряет разработку.
зы
конечно, апологеты "low-code" платформ с этим яростно несогласны ;). ну да бог им судья.
чтобы было понятнее, зачем появился новый cvs, почитайте про страдания fb с гитом, какие у них были с ним проблемы, как их пытались обойти. история легко гуглится.
похоже в fb решили таки решить проблему на корню.
зы
скажем прямо, проблемы fb с гитом не будут возникать у 99.9.. (тут еще некоторое количество 9) % разработчиков.
строго говоря distroless (и ограниченного пользователя) недостаточно.
нужно еще правильные права на каталоги и файлы выставлять.
зы
еще беда, в том числе и моего комментария, в том что сообщается о том что делаем, но не сообщается о том зачем делаем
;))
А зачем вам деление на фиксы, фичи и так далее? Вот вы видите эти коммиты раздельно, и что?
вопрос с подкавыркой ;)
Все верно насчет цели. У каждого она своя.
Допустим я, как-то озадачился, и посчитал свой доход за 10 лет. Потом сравнил с тем, "а что я сейчас имею", очень удивился, что доход утек в самых разных направлениях, активов почти не было. Но куда утек - точно сказать не мог. Вроде бы не кутил, но серьезная сумма дохода ушла в никуда.
Понял что с этим что-то надо делать, и начал вести учет расходов и доходов. 1-й шаг - оптимизировать расходы, все что не соответствует моим целям - безжалостно режется. 2-й шаг - дальше оптимизируем расходы - все ли расходы оптимальны? соответственно в первую очередь обращаем внимание на большие расходные статьи. 3-й шаг - оптимизируем доходы. с ними сложнее, при наемной работе. вначале копишь на депозите. потом ищешь куда можно вложиться. потом считаешь доходы/риски, балансируешь. повторяешь циклы.
И так шаг за шагом, увеличиваешь доходы от неосновной деятельности.
Сейчас уже прошло много лет с того момента, как я начал вести детальный учет расходов. Но продолжаю это делать. Процесс контроля расходов уже устаканился, но раз в полгода, раз в год, сажусь и анализирую что поменялось, хорошо ли это, или плохо, нужно ли корректировать, или наоборот усилить. Да и сам процесс регистрации событий по расходам стал рутиной, отнимает 2-3 минуты в день.
Зачем категории расходов? Очевидно, чтобы ими управлять.
Например, у меня появилась отдельная категория - Здоровье. И расходы по ней у меня не расходы, а инвестиция. Или расходы на образование (мое личное). Это тоже инвестиция. Дальше на большом периоде смотрю, приносит ли инвестиция доходы. Если не приносит, то почему, что нужно поменять. Ну и т.д.
И как итог, за время ведения учета, мои доходы и активы серьезно выросли. Расходы тоже выросли, но меньше. Серьезно поменялось мировоззрение. Вроде бы очевидные вещи, типа без инвестиций не будет дохода, наконец стали не просто теорией, а рутинной практикой. Направления профессионального роста выбираю в том числе и с учетом отношения доходы/усилия. В общем когда есть реальные цифры на руках, принимать правильные решения становится тривиальной задачей.
После добавления инфиксов, пример бы dsl добавить
мне нравится ваша категоричность ;))
ок, чтобы знать на будущее, как называется ситуация, когда у нас есть ограниченный ресурс (отсутствует бюджет на расширение мощностей, либо это произойдет в будущем) и нам необходимо сегодня с этим ресурсом эффективно взаимодействовать. если это не экономия ресурсов, то что?
зависит от вашей реализации. можно сделать чтобы и ожидание ответа было.
вы вот так одним махом перечеркнули reactive-благодетели, такие как circuit breaking, throttling
понятно что reactive рожден для решения проблемы максимальной утилизации cpu для многопоточных приложений, но часть фишек reactive достаются бесплатно. и зачем от них отказываться.
вот есть у нас ограниченный по мощности сервис, он может принимать не более 5 одновременных запросов. если уже сидите на reactive фреймворке, то задача решается элементарно через созданием отдельного scheduler'а. и из коробки у вас есть и ограничение на одновременные запросы, и обработка ошибок при превышении лимитов, и удобный рычаг, который можно крутить в большую или меньшую сторону для управления нагрузкой.
как в случае:
управлять лимитами, мне не очевидно. но наверно тоже можно. мой комментарий был про эту неочевидность.
так и гос-ва тоже может не быть ;)
во всяком случае того, при котором было подписание эп
не туда
OCSP-квитанция. Если ее прикладывать к каждой подписи, это решает проблему ответа на вопрос, а был ли сертификат действительным на момент подписания.
там другое.
представьте, подписан документ 05/12/2022.
сертификат истекает 31/12/2022
на момент подписания сертификат был действительным.
наступает 01/01/2050.
как в 01/01/2050 ответить на вопрос, а был ли на момент подписания 05/12/2022 сертификат действительным?
к тому моменту, УЦ уже может быть закрыт. организация подписанта тоже закрыта. домены истекли. crl-ы где искать? в какой архив бежать?
правда надо отметить, что и для бумажных документов аналогичный вопрос тоже нетривиален.
таск трекеры не панацея, а перекладывание ответственности на заявителя.
даже в шаблонами.
допустим я не шарю с сетевых делах. если при заполнении заявки у меня будут спрашивать про гейтвеи, транки, косы, квоты и т.д. я ничего вразумительного не заполню, даже если начну читать про все эти гейтвеи, транки, косы, квоты и т.д.
ну справедливости ради, реактивщина используется для экономии ресурсов, а под ресурсами может быть не только треды, но и что угодно - сетевые пулы, файловые пулы и т.д.
до чего техника дошла... (с)
Devops - это не про ansible, gitlab, terraform, helm, etc. Технологии вообще не причем.
Devops - про взаимодействие условных девелоперов с условными админами для достижения общих целей. Если идет такой диалог, как в прологе статьи, это не devops. Это яркий пример той проблемы, которая присутствовала в прошлом, и присутствует в настоящем - отсутствие тесного взаимопонимания. И devops как раз вариант решения этой проблемы. Опять же решение не в технологиях, а в том, чтобы условный девелопер и условный админ стали одной командой с единой целью и начали друг с другом конструктивно обсуждать имеющиеся проблемы и возможные решения. И после принятия решения - имплементация может быть в использовании конкретной технологии.
Аналогичная история с Agile. Agile не про спринты, дейлики, ретро и прочее. Agile про тесное взаимопонимание бизнеса и технарей.
Если так, то как реализовать логику: после того как выполнилось это, выполни вот то в неблокирующем стиле?
просто интересно, как это достигается?