All streams
Search
Write a publication
Pull to refresh
4
0

User

Send message

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

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

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 про тесное взаимопонимание бизнеса и технарей.

Реактивный/асинхронный стиль программирования становится практически не нужным.

Если так, то как реализовать логику: после того как выполнилось это, выполни вот то в неблокирующем стиле?

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

просто интересно, как это достигается?

Information

Rating
Does not participate
Registered
Activity