А сами поставщики в итоге знают, что им чего-то не хватает для более плотного сотрудничества? Например компания хочет расти и заполнили анкету. А вы в итоге их отбраковываете. И они не знают, почему. Или все же даете обратную связь, что вы не дотягиваете по уровню ИБ и вам надо подтянуть это и это. Ну и так же вопрос, проверяете ли вы как-то реальность того, что они отвечают?
А что вы в итоге делаете с компаниями, у которых есть некоторые важные огрехи, например нет службы ИБ или антивирусов? Даете им рекомендации по исправлению или у себя режете какие-то привилегии?
На самом деле отличное решение. Когда есть парочка сервисов и не хочется поднимать целую виртуалку с мониторингом, самое то. Это как проблема sentry - есть облегченный аналог GlichTip, которым пользуется довольно много народу, просто потому что облачная версия быстро упирается в лимиты от нескольких ошибок, а стэндэлон версия довольно тяжелая и глючная.
В целом выглядит красиво - свежо!) Меня в яндекс картах подбешивают больше ux особенности и баги (решил тут поделиться наболевшим). причем появились они тоже не слишком давно. например панель супераппа на весь экран, когда ты хочешь просто открыть карту. при поиске почему-то первый раз просто перемещается к нужному участку и нужно нажимать поиск второй раз, чтобы появилась метка на доме. когда нажимаешь маршрут и отменяешь, вьюха то перемещается к точке, то нет, то точка вообще пропадает (а баннер описания с ней остается и переместиться к нему нельзя) так же маршрут бывает перестраивается, бывает нет (чаще нет), когда меняешь направления. и бесячая модалка закончить маршрут, которую можно закрыть успешно только нажатием на кнопку. лет 5 назад все это работало сильно правильнее. А и главную штуку забыл - постоянно неверное направление в москве, хотя компас показывает верное
Выглядит так, как будто это должен быть доклад с презентацией. А теническая часть отдельно. За большим количеством контента сложно поймать основную тему. Но то, что вы сделали наконец авто сертификаты, это круто. Я в свое время из-за этого на Caddy перетащил мелкие проекты, чтобы скрипты не плодить.
Swarm целом хватает для десятка нод., если не нужно супер гибко раскладывать. Странно, что его избегают. По факту l1vestack это аналог swarm, если правильно понял
Как здесь уже упоминали в комментариях, нет стратегии, которая будет работать долгое время - рынок адаптируется, да и в принципе все время меняется за счет смены участников со своими стратегиями (и без них). И к этому реально проще относиться как к игре (PvP). Любая стратегия со временем изживает себя, потому что в рынок приходят те, кто ее делают неработоспособной. А сейчас рынок меняется очень быстро - тестировать стратегию больше чем на пару недель в нынешнее время сложно. И так же нужно постоянно мониторить ее работу и допиливать. В крупных фондах не просто роботы работают - там постоянно сидят дяди, которые что-то подкручивают. Но ваша целеустремленность и продуктивность восхищают конечно.
Я привык использовать conc от sourcegraph - он умеет так же паники перехватывать, чтобы не городить у себя везде конструкции на всякий. И немного других фич, которые идут в комплекте с пулами воркеров. Но в целом да, можно обойтись и стандартной библиотекой, написав свои обертки.
рис тоже не сладкий, но скачки вызывает будь здоров. а ГИ как раз и показывает время, через которое наступит пик. У пюре он высокий и пик реально резкий. я тоже игрался с либрой и глюкометром на подобных продуктах. ну не как у шоколада, меда, колы, но в течение часа уровень улетает до значений, когда хочется размяться. но от порции и других компонентов конечно зависит.
На самом деле адаптируешься. Одежду можно в вакуум упаковывать. Всякий большой хлам можно на месте покупать. Мелкий с собой возить. Девушка тоже привыкает. Рюкзак + чемодан - достаточно для большинства нужд. Некоторые как-то умудряются посуду и подушки с собой возить, но обычно проще их на месте покупать. В общем после 2-3 переездов понимаешь, что нужно, а что нет. И собираться становится легче. С детьми наверное проблема, но учитывая срок жизни детских вещей (по износу и возрасту), то наверное тоже можно переезжать каждые полгода.
я пару месяцев назад поднимал хттп3, правда nginx брал не из хаба готовый, а компилил с добавлением поддержки. в целом все завелось без особых сложностей, если не считать поиск докерфайла на гитхабе готового.
Это кстати большой недостаток го, так как ошибку в случайной горутине нельзя отловить и отправить, например в сентри. В простых веб-сервисах это решается милдварями/библиотеками, которые оборачивают каждую горутину. Но в более сложных, автоматических вариантов как в питоне, к примеру (добавил пару строчек и забыл), я не нашел.
Деплоя с конфигом явно не хватало. А как миграции происходят. Например, я запускаю инстанс в докере и хочу добавить индекс. Просто меняю конфиг и дергаю какую-то ручку? Или все же миграции нужно запускать руками в виде скриптов?
Соглашусь с предыдущими комментаторами. Нужно обязательно написать про slog. Он решает основные проблемы старого логгера. А так из сторонних zerolog мне лично больше зашел
в пхп вообще почти все смотрится как прибывшее из ада. я покодил на нем пару лет и забыл как страшный сон именно из-за тяжелочитемых конструкций, особенно в фреймворках
но вообще все сложнее - есть тяжелые костыльные орм, типа горма, а есть бойлер, или реформ (если брать го). которые избавляют от написания повторной логики (и части опечаток в запросах) и синхронизации структур с базой, добавляют комплит. в обоих есть билдеры запросов.
в джанге же орм наоброт является ведущей, что тоже избавляет от повторности и очень помогает следить за базой. при этом более 90 процентов запросов в джанге выглядят очень просто. остальные 5 процентов можно и вручную написать.
В целом верно - для каждой задачи можно найти более подходящий язык. Но (если задача не очень простая) он не будет идеальным и придется делать что-то нестандартное.
Python удобен с его кучей батареек (одна только админка django чего стоит), но на нем всегда есть соблазн уйти в оверинжиниринг, когда выходит что-то околоджавное - 10 наследований + миксины. Но если нужно сделать асинхронный код, который легко читать и поддерживать, то go показывает себя с лучшей стороны.
Идеального языка нет (могу сказать, как писавший минимум на десятке), мир не двухполярный. Поэтому у каждого языка есть варианты, как обойти ограничения. У питона есть threadpool и asyncio, которые могут позволить сделать быстрый парсер (но оба решения не без недостатков). У го есть рефлект, который позволяет удобно разбирать json. При этом так же есть вариант парсить и без рефлекта, когда нужна ультра-производительность. Вопрос в том, что ультра-производительность нужна обычно в других местах кода, а разобрать и собрать json, это вторичная операция.
А сами поставщики в итоге знают, что им чего-то не хватает для более плотного сотрудничества? Например компания хочет расти и заполнили анкету. А вы в итоге их отбраковываете. И они не знают, почему. Или все же даете обратную связь, что вы не дотягиваете по уровню ИБ и вам надо подтянуть это и это.
Ну и так же вопрос, проверяете ли вы как-то реальность того, что они отвечают?
А что вы в итоге делаете с компаниями, у которых есть некоторые важные огрехи, например нет службы ИБ или антивирусов? Даете им рекомендации по исправлению или у себя режете какие-то привилегии?
На самом деле отличное решение. Когда есть парочка сервисов и не хочется поднимать целую виртуалку с мониторингом, самое то. Это как проблема sentry - есть облегченный аналог GlichTip, которым пользуется довольно много народу, просто потому что облачная версия быстро упирается в лимиты от нескольких ошибок, а стэндэлон версия довольно тяжелая и глючная.
В целом выглядит красиво - свежо!)
Меня в яндекс картах подбешивают больше ux особенности и баги (решил тут поделиться наболевшим). причем появились они тоже не слишком давно. например панель супераппа на весь экран, когда ты хочешь просто открыть карту. при поиске почему-то первый раз просто перемещается к нужному участку и нужно нажимать поиск второй раз, чтобы появилась метка на доме. когда нажимаешь маршрут и отменяешь, вьюха то перемещается к точке, то нет, то точка вообще пропадает (а баннер описания с ней остается и переместиться к нему нельзя)
так же маршрут бывает перестраивается, бывает нет (чаще нет), когда меняешь направления. и бесячая модалка закончить маршрут, которую можно закрыть успешно только нажатием на кнопку. лет 5 назад все это работало сильно правильнее.
А и главную штуку забыл - постоянно неверное направление в москве, хотя компас показывает верное
Выглядит так, как будто это должен быть доклад с презентацией. А теническая часть отдельно. За большим количеством контента сложно поймать основную тему. Но то, что вы сделали наконец авто сертификаты, это круто. Я в свое время из-за этого на Caddy перетащил мелкие проекты, чтобы скрипты не плодить.
Swarm целом хватает для десятка нод., если не нужно супер гибко раскладывать. Странно, что его избегают. По факту l1vestack это аналог swarm, если правильно понял
Как здесь уже упоминали в комментариях, нет стратегии, которая будет работать долгое время - рынок адаптируется, да и в принципе все время меняется за счет смены участников со своими стратегиями (и без них). И к этому реально проще относиться как к игре (PvP). Любая стратегия со временем изживает себя, потому что в рынок приходят те, кто ее делают неработоспособной. А сейчас рынок меняется очень быстро - тестировать стратегию больше чем на пару недель в нынешнее время сложно. И так же нужно постоянно мониторить ее работу и допиливать. В крупных фондах не просто роботы работают - там постоянно сидят дяди, которые что-то подкручивают.
Но ваша целеустремленность и продуктивность восхищают конечно.
Я привык использовать conc от sourcegraph - он умеет так же паники перехватывать, чтобы не городить у себя везде конструкции на всякий. И немного других фич, которые идут в комплекте с пулами воркеров. Но в целом да, можно обойтись и стандартной библиотекой, написав свои обертки.
рис тоже не сладкий, но скачки вызывает будь здоров. а ГИ как раз и показывает время, через которое наступит пик. У пюре он высокий и пик реально резкий. я тоже игрался с либрой и глюкометром на подобных продуктах. ну не как у шоколада, меда, колы, но в течение часа уровень улетает до значений, когда хочется размяться. но от порции и других компонентов конечно зависит.
На самом деле адаптируешься. Одежду можно в вакуум упаковывать. Всякий большой хлам можно на месте покупать. Мелкий с собой возить. Девушка тоже привыкает. Рюкзак + чемодан - достаточно для большинства нужд. Некоторые как-то умудряются посуду и подушки с собой возить, но обычно проще их на месте покупать. В общем после 2-3 переездов понимаешь, что нужно, а что нет. И собираться становится легче.
С детьми наверное проблема, но учитывая срок жизни детских вещей (по износу и возрасту), то наверное тоже можно переезжать каждые полгода.
есть еще вариант от команды в рф - форк angie - там хттп3 из коробки, но конфиг чуть не совместим из-за названия nginx в директивах)
я пару месяцев назад поднимал хттп3, правда nginx брал не из хаба готовый, а компилил с добавлением поддержки. в целом все завелось без особых сложностей, если не считать поиск докерфайла на гитхабе готового.
У nginx кстати есть свой бесплатный проверятор, правда он по другому работает - nginx amplify
Это кстати большой недостаток го, так как ошибку в случайной горутине нельзя отловить и отправить, например в сентри. В простых веб-сервисах это решается милдварями/библиотеками, которые оборачивают каждую горутину. Но в более сложных, автоматических вариантов как в питоне, к примеру (добавил пару строчек и забыл), я не нашел.
Деплоя с конфигом явно не хватало. А как миграции происходят. Например, я запускаю инстанс в докере и хочу добавить индекс. Просто меняю конфиг и дергаю какую-то ручку? Или все же миграции нужно запускать руками в виде скриптов?
Соглашусь с предыдущими комментаторами. Нужно обязательно написать про slog. Он решает основные проблемы старого логгера. А так из сторонних zerolog мне лично больше зашел
в пхп вообще почти все смотрится как прибывшее из ада. я покодил на нем пару лет и забыл как страшный сон именно из-за тяжелочитемых конструкций, особенно в фреймворках
выглядит как будто чатгпт скомпилировал)
но вообще все сложнее - есть тяжелые костыльные орм, типа горма, а есть бойлер, или реформ (если брать го). которые избавляют от написания повторной логики (и части опечаток в запросах) и синхронизации структур с базой, добавляют комплит. в обоих есть билдеры запросов.
в джанге же орм наоброт является ведущей, что тоже избавляет от повторности и очень помогает следить за базой. при этом более 90 процентов запросов в джанге выглядят очень просто. остальные 5 процентов можно и вручную написать.
Если знаешь один язык, книги уже не нужны. С нуля определенной аудитории понимать через книги проще
В целом верно - для каждой задачи можно найти более подходящий язык. Но (если задача не очень простая) он не будет идеальным и придется делать что-то нестандартное.
Python удобен с его кучей батареек (одна только админка django чего стоит), но на нем всегда есть соблазн уйти в оверинжиниринг, когда выходит что-то околоджавное - 10 наследований + миксины. Но если нужно сделать асинхронный код, который легко читать и поддерживать, то go показывает себя с лучшей стороны.
Идеального языка нет (могу сказать, как писавший минимум на десятке), мир не двухполярный. Поэтому у каждого языка есть варианты, как обойти ограничения. У питона есть threadpool и asyncio, которые могут позволить сделать быстрый парсер (но оба решения не без недостатков). У го есть рефлект, который позволяет удобно разбирать json. При этом так же есть вариант парсить и без рефлекта, когда нужна ультра-производительность. Вопрос в том, что ультра-производительность нужна обычно в других местах кода, а разобрать и собрать json, это вторичная операция.