Ростелеком, Газпром, Мэйл (VK), ВТБ + Сбер и прочие банки... А еще вся цепочка их дочек. За последние пару лет половина вакансий это импортозамещение. Все крупные компании делают (дорабатываю) примерно одно и тоже ). Компании по меньше пытаются найти на рынке РФ, что попроще.
И это я говорю про банальное перекладывание циферок и джейсончиков. Есть и менее попсовые и узкоспециализированные продуты, что стали подгорать.
Есть такой проект https://www.asyncapi.com/ Основная проблема в подобных проектах заключается в том, что, в отличие от HTTP, в RMQ все взаимодействие происходит "кто во что горазд". Поэтому сложно найти вещи типа swagger.
Меня смущает эта дыра в грунте. А смущает тк вроде как планировали на марсе и луне сажать именно на грунт и взлетать с него. Или движки первой ступени на земле работают совершенно иным образом?)
И очень размеренный формат жизни экосистемы. Год в библиотеке без комитов это норма. Просто нет необходимости в этой суете. Жаль только емкость рынка маленькая.
Ну не совсем так. Я знаю что банки из топ 5(10 и 20) по стране ищут варианты частичного замещения. Например в части скоринга и СПР. Так же знаю, что Центробанк так же проводит переговоры с отечественными компаниями.
PS: Подробностей не будет, тк это проходит мимо меня (очень с краю). Компания занимается автоматизацией процессов для банков. Уверен, что это сейчас происходит среди всех заинтересованных. Банки это крайне инертные структуры. Быстро они не меняются.
Единственное «НО»- язык запросов clojure.
Как следствие этого мощные возможности по работе с данными, но необходимость минимально погрузится (к слову сказать погружение должно пройти быстро и легко).
Зато получаем ЛЕГКИЙ, ПРОСТОЙ и МОЩНЫЙ язык для запросов и трансформаций.
У Тепловых насосов КПД выше 100% (на киловатт электроэнергии вырабатывается 1+ киловатт, за счет внешней среды). Смущает лишь вложения на строительство. Миллион +- это сурово.
Геотермальные (как и прочие) тепловые насосы используют как для обогрева так и для охлаждения.
Принцип работы ТН на пальцах это холодильник (где радиатор помещают в некую среду).
Более простой вариант — коллектор в грунте. Минус в том что его периодически промывать надо и обеззараживать. Выпадающий конденсат создает прекрасные условия для размножения всякой гадости.
PS: Кондиционеры тоже умеют нагревать. Некоторые даже до -20 на улице работать умеют.
Для глуши тоже маловато. У меня родственники в деревне в Крыму живут. 1-1.5 млн для разваливающегося деревенского дома это нормально. Цены после 14 г. взлетели просто сумасшедшим образом.
Было время, сам делал распознавание номерных знаков.
Печаль моя не имела границ т.к. мои входные данные были в разы хуже чем для коммерческих аналогов. Так и не удалось добиться стабильных результатов.
Не могли бы вы указать приблизительные требования для входной картинки (Размеры номерного знака, допустимые углы отклонения)
PS: + за решенную задачу :)
Многословность. В моем понимании в let блок должен быть максимально лаконичным. with-lot-fn, buy-lot-fn вынести наружу. buy-lot-fn разбить для более легкого понимания.
Лично меня начинает клинить если в функции большая вложенность.
Вложенные let блоки причиняют страдания.
Всё это разумеется ИМХО
Пишу сейчас процессинг. Море операций с файловой системой, базой данных, сторонними сервисами и программами. Пришел к похожей схеме с различием в структуре данных.
Для себя остановился на funcool/cats и монаде Either.
PS: Ваш блок let функции buy-lot заставляет моё сердце кровоточить :)
Как всегда. Сначала мы радуемся «документоорентированному» варианту хранения данных.
Вложенные объекты… Все в одном месте…
А потом мы потихоньку приходим к мысли, что структура данных должна быть плоской.
По этим граблям должен пройти каждый :)
PS: normalizr
Перед мной стоит задача запустить несколько потоков слежения за некими сущностями в сети. Сущностей может быть много(10,20,100). А частота опроса не должна сильно плавать. При всем при этом мы хотим этим сущностям посылать команды и контролировать результат выполнения команды.
Первое желание сделать это через цикл в го форме с двумя каналами (in/out). Но так как они будут выполняться в общем пуле потоков мы можем получить залипание отдельных циклов.
Можно запускать циклы в future (или вовсе оборачивать в Thread) а каналы реализовывать через общие атомы. Вот только в таком случае нам придется часть функционала core.async переписывать своими ручками.
Вот и как быть? :)
Ростелеком, Газпром, Мэйл (VK), ВТБ + Сбер и прочие банки... А еще вся цепочка их дочек.
За последние пару лет половина вакансий это импортозамещение. Все крупные компании делают (дорабатываю) примерно одно и тоже ). Компании по меньше пытаются найти на рынке РФ, что попроще.
И это я говорю про банальное перекладывание циферок и джейсончиков. Есть и менее попсовые и узкоспециализированные продуты, что стали подгорать.
Pydantic умеет генерировать json-sсhema, а entity там как раз они (вроде как)
А вот все остальное ручками. Это да.
Или я не прав?
Есть такой проект https://www.asyncapi.com/
Основная проблема в подобных проектах заключается в том, что, в отличие от HTTP, в RMQ все взаимодействие происходит "кто во что горазд". Поэтому сложно найти вещи типа swagger.
Меня смущает эта дыра в грунте. А смущает тк вроде как планировали на марсе и луне сажать именно на грунт и взлетать с него. Или движки первой ступени на земле работают совершенно иным образом?)
И очень размеренный формат жизни экосистемы. Год в библиотеке без комитов это норма. Просто нет необходимости в этой суете.
Жаль только емкость рынка маленькая.
Ну не совсем так. Я знаю что банки из топ 5(10 и 20) по стране ищут варианты частичного замещения. Например в части скоринга и СПР. Так же знаю, что Центробанк так же проводит переговоры с отечественными компаниями.
PS: Подробностей не будет, тк это проходит мимо меня (очень с краю). Компания занимается автоматизацией процессов для банков. Уверен, что это сейчас происходит среди всех заинтересованных. Банки это крайне инертные структуры. Быстро они не меняются.
https://airbrake.io/ не доступен с территории РФ.
Странно, но не где не видел информации об этом.
github.com/borkdude/jet/blob/master/doc/query.md
Единственное «НО»- язык запросов clojure.
Как следствие этого мощные возможности по работе с данными, но необходимость минимально погрузится (к слову сказать погружение должно пройти быстро и легко).
Зато получаем ЛЕГКИЙ, ПРОСТОЙ и МОЩНЫЙ язык для запросов и трансформаций.
Простой пример
Пример использования одного из JQ example (https://stedolan.github.io/jq/tutorial/)
Принцип работы ТН на пальцах это холодильник (где радиатор помещают в некую среду).
Более простой вариант — коллектор в грунте. Минус в том что его периодически промывать надо и обеззараживать. Выпадающий конденсат создает прекрасные условия для размножения всякой гадости.
PS: Кондиционеры тоже умеют нагревать. Некоторые даже до -20 на улице работать умеют.
Вот пример номерного знака
На сколько вероятно правильное распознавание?
Печаль моя не имела границ т.к. мои входные данные были в разы хуже чем для коммерческих аналогов. Так и не удалось добиться стабильных результатов.
Не могли бы вы указать приблизительные требования для входной картинки (Размеры номерного знака, допустимые углы отклонения)
PS: + за решенную задачу :)
У меня например появилось 3 gist.
Создал пока пытался понять что же я делаю не правильно.
Не создаются Gist, но ты понимаешь об этом только давая ссылку на gist.
Многословность. В моем понимании в
letблок должен быть максимально лаконичным.with-lot-fn,buy-lot-fnвынести наружу.buy-lot-fnразбить для более легкого понимания.Лично меня начинает клинить если в функции большая вложенность.
Вложенные
letблоки причиняют страдания.Всё это разумеется ИМХО
Пишу сейчас процессинг. Море операций с файловой системой, базой данных, сторонними сервисами и программами. Пришел к похожей схеме с различием в структуре данных.
Для себя остановился на funcool/cats и монаде Either.
PS: Ваш блок
letфункцииbuy-lotзаставляет моё сердце кровоточить :)Вложенные объекты… Все в одном месте…
А потом мы потихоньку приходим к мысли, что структура данных должна быть плоской.
По этим граблям должен пройти каждый :)
PS:
normalizr
Первое желание сделать это через цикл в го форме с двумя каналами (in/out). Но так как они будут выполняться в общем пуле потоков мы можем получить залипание отдельных циклов.
Можно запускать циклы в future (или вовсе оборачивать в Thread) а каналы реализовывать через общие атомы. Вот только в таком случае нам придется часть функционала core.async переписывать своими ручками.
Вот и как быть? :)