Есть впечатление, что ajile и кризисный подход одно и то же. Интерактивная разработка с ожидаемой и проверяемой ценностью на каждом этапе. Не путать со скрамом и другими довольно жёстким фреймворками. Принципы Kanban как бы ортогональны. Если горе менеджеры наплодили 53 этапа на доске, то больших им успехов. В промышленности, когда цикл от заказа до поставки занимает от полугода, отлично работают и жёсткие календарных планы и кабан.
Существует мнение, что для 90+% проектов можно обойтись без дополнительного кэширования. Postgre выдаёт десятки тысяч RPS на далеко не топовом железе, а средний слой часто намного менее прожорлив и легко горизонтально масштабируется. Неприменимо, если у вас 5 микросервисов выстроенных в ряд друг за другом.
Статья отличная. Увы, разделение и перекладывание ответственности удел практически любой корпорации. Сотрудлники, умеющие разделять ответственность и перекладывать риски выживают и растут в них просто отлично. Я часто выступаю и с той и с другой стороны. В продуктовых менеджерах меня чаще выбешивает повышенное ожидание от продукта как от золотой пули, в то время, как бизнес улучшается через изменение процессов и продуктов. При этом продуктовый менеджер часто не является владельцем процесса, но отказывается или боится драйвить его изменение.
Если я верно понял, то щейх потратился на покупку актива, расплатившись стэйблкойном имеющим отношение к Трампу за 2 недели до подписания разрешения на импорт чипов. Шейх в плюсе, т.к. сделал трампу приятное, Binance в плюсе, т.к. имеет прямое существенное влияние на этот стэйблкойн и это упрочняет её переговорную позицию по рынку в США. Все довольны и взяткой, тем более на 2 млд. USD это назвать сложно. Я пока не вижу никаких предпосылок к преследованию, если за кулисами не было предварительных договоренностей. Но про такое можно и не говорить. Все и так всё прекрасно понимают. Деньги налогоплательщиков не тронуты так же как и интересы США. Импорт в любой момент можно запретить, если что-то пойдёт не так.
Уфф. На практике с коллегами и клиентами понял, что общаюсь стандартными фразами, которые немного изменяю. Условно для бизнеса и ИТ это не такой большой набор. Грамматика при этом хронически проседала, т.к. в школе учил другой язык, в ВУЗе английского почти не было. Все попытки вытянуть грамматику на условный B2 были только временными, т.к. не использую я все времена в разных залогах и будучи подтянутой эта грамматика быстро забывается, так как не используется. Поэтому, условный Present Perfect Continuous я использую, но только в стандартных фразах аля I have been working on .... Возможно, я просто не грамотный. С русской грамматикой у меня так же тухло.
Думаю, что есть проблема в самой модели. Начиная со стоимости задачи, которая в реальном мире часто декомпозируется и разделяется по исполнителям, которые обладают нужными знаниями. Парно кодить это не только сложение компетенций по направлениям (например, GO и SQL), но более долгая концентрация, возможность обсудить что-то с тем, кто всегда в контексте. Ещё не обязательно иметь одинаковый грейд. Меня, например, работа с джунами отлично бустит и их, я надеюсь, тоже.
Для хотфиксов есть универсальный поход с созданием таблицы, куда складываются оригинальные данные, а потом уже запрос на удаление. Лучше с условием по этой таблице, но не обязательно. Обычно достаточно копипаста из выюорки для новой таблицы.
Это позволит откатить изменение, если что то пошло не так.
Немного не понял про негатив с агентским режимом и отладкой через консоль в курсоре. В процессе отладки LLM добавляет в цикле отладочную информацию пока не локализует ошибку, а затем её чинит. И агентский режим в топ моделях отлично это обрабатывает. Правда, я прошу ввести новый уровень логгирования для таких кейсов. Условный LLM debug.
Ну вот я могу с наскока int или string мутабельным назвать. Вроде база, но когда python твой 4й язык из тех, что регулярно используешь, то можешь и забыть. Зато могу рассказать с подробностями иивнутрянкой про сложение строк в цикле через +, join и StringIO. LLM часто плюсами обходятся и приходится ей тыкать:(
Как в прошлом сотрудник Русала давно жду батарейку на алюминии. Металл активный, окисляется шустро, крошится легко, энергоёмкость порядка 30 МДЖ/кг против 42 у дизельного топлива. Заправлять можно пластинами, а оксид сдавать на переработку.
В детстве и юности лето проводил в деревне. Дрова, трава, пчёлы скотина разная. Не так давно был проект в сельском хозяйстве с мега коровниками, сырным заводом и прочими промышленными активностями. И вот в современную "деревню", где телёнок от человека шарахается. т.к. тот его не кормит, а только прививки ставит, не хочется совсем. Очень рад, что остались ещё островки хоть и экзотической, но не промышленной сельской жизни. Хотя страусы такое себе.. Не самый контактный зверь. Больше на зоопарк напоминает.
Спасибо. Я верно понял, что FOR NO KEY UPDATE подходит для блокировки чтения не ключевых атрибутов? Например, если по строке есть ссылка на клиента и сумма, а я внутри транзакции изменяю только смму, то будет достотачно применить FOR NO KEY UPDATE? Про каскадные блокировки пойду почитаю с подробностями.
Вот поддержу про отсутствие лидеров. SAP и Oracle конечно продавали в догонку к ERP свои BI решения, но PowerBI, Tableau занимали намного большую долю.
Критерии странные как и выбор продуктов для импортозамещения.
Ну это же история про оптимистичные и пессимистичные блокировки. И про то, что foreign key приводит к каскадным блокировкам в рамках SQL стандарта (вот про стандарт могу приврать). Правильный подход - foreign key не использовать, select for update использовать для того, чтобы проверить, что с момента последнего чтения запись (иногда несколько да ещё и в связанных сущностях) не изменилась и если не изменилась, то записать. Если блокировать на время проверки не будете, то между чтением и записью может кто-нибудь вклиниться. Этот кейс особенно актуален для программ, связанным с финансами, материальными ценностями, ключевыми справочниками. Мало актуален для большинства транзакций в e-commerce, но и там тоже обязательно встречается.
Мо мне приведенный пример с факт чекингом вполне является компонентом критического мышления. Оно не обязано быть комплексным в каждом своём проявлении. Вспоминается книжка классическая книжка "Thinking, Fast and Slow " в которой показано, что осмысленные решения это дорогой и медленный процесс. Увидел то, что цепляет. Проверил, что цеплялка фейковая и поехал жить дальше.
Заметил, что чаще исходные данные у меня доступны через SQL. Поэтому основные фильтры, аналитические и оконные функции использую обычно оттуда. А вот окончательную очистку данных для моделек делаю в pandas, если данных не сильно много, конечно.
Есть впечатление, что ajile и кризисный подход одно и то же. Интерактивная разработка с ожидаемой и проверяемой ценностью на каждом этапе. Не путать со скрамом и другими довольно жёстким фреймворками. Принципы Kanban как бы ортогональны. Если горе менеджеры наплодили 53 этапа на доске, то больших им успехов. В промышленности, когда цикл от заказа до поставки занимает от полугода, отлично работают и жёсткие календарных планы и кабан.
Существует мнение, что для 90+% проектов можно обойтись без дополнительного кэширования. Postgre выдаёт десятки тысяч RPS на далеко не топовом железе, а средний слой часто намного менее прожорлив и легко горизонтально масштабируется. Неприменимо, если у вас 5 микросервисов выстроенных в ряд друг за другом.
Статья отличная. Увы, разделение и перекладывание ответственности удел практически любой корпорации. Сотрудлники, умеющие разделять ответственность и перекладывать риски выживают и растут в них просто отлично. Я часто выступаю и с той и с другой стороны. В продуктовых менеджерах меня чаще выбешивает повышенное ожидание от продукта как от золотой пули, в то время, как бизнес улучшается через изменение процессов и продуктов. При этом продуктовый менеджер часто не является владельцем процесса, но отказывается или боится драйвить его изменение.
Если я верно понял, то щейх потратился на покупку актива, расплатившись стэйблкойном имеющим отношение к Трампу за 2 недели до подписания разрешения на импорт чипов.
Шейх в плюсе, т.к. сделал трампу приятное, Binance в плюсе, т.к. имеет прямое существенное влияние на этот стэйблкойн и это упрочняет её переговорную позицию по рынку в США.
Все довольны и взяткой, тем более на 2 млд. USD это назвать сложно.
Я пока не вижу никаких предпосылок к преследованию, если за кулисами не было предварительных договоренностей. Но про такое можно и не говорить. Все и так всё прекрасно понимают. Деньги налогоплательщиков не тронуты так же как и интересы США. Импорт в любой момент можно запретить, если что-то пойдёт не так.
Уфф.
На практике с коллегами и клиентами понял, что общаюсь стандартными фразами, которые немного изменяю. Условно для бизнеса и ИТ это не такой большой набор. Грамматика при этом хронически проседала, т.к. в школе учил другой язык, в ВУЗе английского почти не было. Все попытки вытянуть грамматику на условный B2 были только временными, т.к. не использую я все времена в разных залогах и будучи подтянутой эта грамматика быстро забывается, так как не используется. Поэтому, условный Present Perfect Continuous я использую, но только в стандартных фразах аля I have been working on ....
Возможно, я просто не грамотный. С русской грамматикой у меня так же тухло.
Думаю, что есть проблема в самой модели. Начиная со стоимости задачи, которая в реальном мире часто декомпозируется и разделяется по исполнителям, которые обладают нужными знаниями.
Парно кодить это не только сложение компетенций по направлениям (например, GO и SQL), но более долгая концентрация, возможность обсудить что-то с тем, кто всегда в контексте. Ещё не обязательно иметь одинаковый грейд. Меня, например, работа с джунами отлично бустит и их, я надеюсь, тоже.
Предлагаю сделать терминал ещё более "умным", добавив к всплывающим подсказкам рекламные фразы, начинающиеся с тех же начальных букв.
Для хотфиксов есть универсальный поход с созданием таблицы, куда складываются оригинальные данные, а потом уже запрос на удаление. Лучше с условием по этой таблице, но не обязательно. Обычно достаточно копипаста из выюорки для новой таблицы.
Это позволит откатить изменение, если что то пошло не так.
Немного не понял про негатив с агентским режимом и отладкой через консоль в курсоре. В процессе отладки LLM добавляет в цикле отладочную информацию пока не локализует ошибку, а затем её чинит. И агентский режим в топ моделях отлично это обрабатывает. Правда, я прошу ввести новый уровень логгирования для таких кейсов. Условный LLM debug.
Ну вот я могу с наскока int или string мутабельным назвать. Вроде база, но когда python твой 4й язык из тех, что регулярно используешь, то можешь и забыть. Зато могу рассказать с подробностями иивнутрянкой про сложение строк в цикле через +, join и StringIO. LLM часто плюсами обходятся и приходится ей тыкать:(
Год назад был Сигнал, теперь Макс. Через какое время появится следующий? Поставить лично мне и моим детям школьникам придётся.
Лично мне не хватает сравнения с тем же ТГ хотя бы по разрешениям.
Как в прошлом сотрудник Русала давно жду батарейку на алюминии. Металл активный, окисляется шустро, крошится легко, энергоёмкость порядка 30 МДЖ/кг против 42 у дизельного топлива. Заправлять можно пластинами, а оксид сдавать на переработку.
В детстве и юности лето проводил в деревне. Дрова, трава, пчёлы скотина разная. Не так давно был проект в сельском хозяйстве с мега коровниками, сырным заводом и прочими промышленными активностями. И вот в современную "деревню", где телёнок от человека шарахается. т.к. тот его не кормит, а только прививки ставит, не хочется совсем.
Очень рад, что остались ещё островки хоть и экзотической, но не промышленной сельской жизни. Хотя страусы такое себе.. Не самый контактный зверь. Больше на зоопарк напоминает.
Я бы таблицу с тарифам добавил. У того же Яндекса годовая подписка на семью, где у каждого терабайт+ получается порядка 3000 руб на 8 человек.
Спасибо. Я верно понял, что FOR NO KEY UPDATE подходит для блокировки чтения не ключевых атрибутов? Например, если по строке есть ссылка на клиента и сумма, а я внутри транзакции изменяю только смму, то будет достотачно применить FOR NO KEY UPDATE? Про каскадные блокировки пойду почитаю с подробностями.
Вот поддержу про отсутствие лидеров. SAP и Oracle конечно продавали в догонку к ERP свои BI решения, но PowerBI, Tableau занимали намного большую долю.
Критерии странные как и выбор продуктов для импортозамещения.
Откуда такой странный список работодателей? Спонсоры? Или для каждого участника свой список?
Ну это же история про оптимистичные и пессимистичные блокировки. И про то, что foreign key приводит к каскадным блокировкам в рамках SQL стандарта (вот про стандарт могу приврать).
Правильный подход - foreign key не использовать, select for update использовать для того, чтобы проверить, что с момента последнего чтения запись (иногда несколько да ещё и в связанных сущностях) не изменилась и если не изменилась, то записать. Если блокировать на время проверки не будете, то между чтением и записью может кто-нибудь вклиниться. Этот кейс особенно актуален для программ, связанным с финансами, материальными ценностями, ключевыми справочниками. Мало актуален для большинства транзакций в e-commerce, но и там тоже обязательно встречается.
Мо мне приведенный пример с факт чекингом вполне является компонентом критического мышления. Оно не обязано быть комплексным в каждом своём проявлении.
Вспоминается книжка классическая книжка "Thinking, Fast and Slow " в которой показано, что осмысленные решения это дорогой и медленный процесс. Увидел то, что цепляет. Проверил, что цеплялка фейковая и поехал жить дальше.
Заметил, что чаще исходные данные у меня доступны через SQL. Поэтому основные фильтры, аналитические и оконные функции использую обычно оттуда. А вот окончательную очистку данных для моделек делаю в pandas, если данных не сильно много, конечно.