Можно ли построить прибыльную алгоритмическую систему для реальной торговли на фондовых рынках? Какие ошибки совершают новички при бэктестах алго-систем и как их избежать. Попробую ответить на эти вопросы под катом.

В этой статье я хотел бы рассказать о различиях между сборкой мусора в Unity (IL2CPP) и .NET. Несмотря на то что IL2CPP существует более 10 лет, я до сих пор встречаю недоумение, когда беседа заходит на тему Garbage Collector (GC) касательно Unity. Считать реализацию GC в .NET, ровно как и в JVM, единственным существующим решением — не верно. А тем более принимать такую реализации как "по умолчанию" используемую в Unity — есть заблуждение. Надеюсь эта статья будет полезной, даст верное понимание и устранит заблуждения. Ну а в конце статьи затронем грядущие серьезные изменения в Unity.

Что такое конечные автоматы?

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

Бывает встречаются Unix-системы, на которых некоторые администраторы передают процессам пароли в открытом виде, совершенно не заботясь о том, что их видят все пользователи данной системы.

Если вы смогли зайти на систему под непривилегированным пользователем, то вы можете набрать команду, отображающую список запущенных процессов

$ ps -ef

и возможно и увидеть некоторые секреты, которых видеть не должны, например, у одного из процессов ниже открыт пароль basicAuth.password (пароль в тексте изменен).

$ strings /proc/1101/cmdline /usr/local/bin/vmagent --remoteWrite.url=http://vm-cluster.local:1234/api/v1/write --remoteWrite.basicAuth.username=user-rw --remoteWrite.basicAuth.password=123456 --promscrape.config=/usr/local/etc/vmagent-config.yml

Как же быть? Есть несколько способов этого избежать.

Трудности в процессе разработки на Go — частая история. Чтобы их преодолеть, нам даже пришлось писать собственный бойлерплейт. Хотя казалось бы — всё уже есть, но нет, нам понадобилось имплементировать собственную хардкорную штуку. Расскажем, почему и зачем.

Всем привет, на связи Пётр, инженер компании Nixys. В прошлой статье мы разобрали основные концепции Redis. Теперь рассмотрим базовую репликацию Redis и настроим эту БД на высокий уровень отказоустойчивости.

Давным-давно, когда Linux был ещё на ядре 2.6, а PHP5 был глотком свежего воздуха, я впервые заинтересовался миром веб-технологий. Читал учебники, статьи, зависал на форумах, но все равно мало мог понять как код, который я вижу на экране, превращается в волшебные сайты с кнопками, формами и анимациями. Узнал про LAMP и его аналоги для Windows, узнал, что, оказывается, есть хостинги, где такие сайты размещаются. Как только появился внешний интернет без трафика, я поспешил перенести свои локальные поделия во внешний мир, попутно узнав про замечательный протокол FTP. Просто мир волшебных открытий был для меня, особенно когда узнал, что не нужно писать свой форум с нуля, а можно использовать что-то из phpBB, vBulletin и других уже готовых движков.

И когда я много лет спустя переключился в мир .NET, перечисленные ранее умения сыграли со мной злую шутку – я долго не мог понять, как мне найти хостинг для .NET приложений. Почему все известные мне хостинги с лёгкостью предоставляли возможность развернуть PHP приложения, причём даже предлагая какие-то предустановленные версии CMS, но днём с огнём не сыщешь хостинг под .NET. Мое непонимание принципа развертывания приложений усугубляли статьи, которые предлагали их размещать в подходящих сервисах типа Heroku, Digital Ocean или Azure – ведь это так просто и дешево…

Поэтому предлагаю максимально подробно рассмотреть вопрос публикации .NET приложений в арендованном VPS.

Часто в больших компания всё поделено на большие системы. А если система «Legacy», т.е. устаревшая, то часто внутри неё собрано очень много разнородного функционала. По сути такие системы представляют из себя монолитных монстров.

Бывает, что компании решают использовать микросервисный подход, но в результате получают таких же монолитных монстров, но только работающих в Кубере.

Границы систем размыты, нет чёткого понимания, что должно входить в систему, а что нет.

Команды сильно специализированы на конкретную систему и не могут участвовать в доработке никакой другой системы.

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

Можно ли исправить ситуацию коренным образом?

Представим следующую задачу: у нас есть микросервисная архитектура, в которой сервисы взаимодействуют через брокер сообщений, или через gRPC. Так или иначе, оба варианта предоставляют полнодуплексный канал связи, через который один сервис может отправлять множество сообщений другому сервису, так и в обратную сторону - сервис, исполняющий запрос, может отправлять несколько ответов (например в случае потоковой обработки данных). Такой вариант реализации ответа можно в некотором смысле называть стримингом.

В числе прочих задач, решаемых при реализации возможности стриминга, существует задача определения ситуации, в которой сервис, исполняющий запрос, упал с ошибкой, и больше не может продолжать стриминг ответов. В таком случае мы даже не можем понять что именно произошло - обработка и отдача очередной порции ответа будет, но задерживается, либо же передача прервалась, и нужно сообщить об ошибке “наверх”. В протоколе HTTP, например, для детерминирования корректной вычитки ответа может быть использован заголовок Content-Length. Достаточно посчитать количество вычитанных из сокета байт тела запроса\ответа, и сравнить со значением заголовка. Сходится - мы все получили, не сошлось и сокет закрыт - ошибка. Однако вариант решения с заранее заданным количеством данных в первой порции ответов не является универсальным, поскольку не во всех случаях можно точно понимать, сколько именно данных будет передано. Да и архитектура с использованием брокеров сообщений предполагает постоянное поддержание соединения, поэтому мы можем только знать, что из такой-то очереди поступают ответы на ранее сделанный запрос, и в каком-то из ответов будет метка окончания, как маркер того, что запрос обработан и ответ выслан и получен полностью, а если такого маркера еще не получено - остается продолжать ждать. Но ждать можно бесконечно.

Эта статья о том, что появилось нового в генераторе исходного кода Pure.DI с момента выхода предыдущей статьи Pure.DI v2.1. Помимо исправления некоторых ошибок основной акцент был сделан на упрощении использования API для настройки генерации кода. Появилась возможность определить корни композиции обобщенных типов. Добавились накопители, что решило вопрос утилизации объектов со временем жизни отличным от Lifetime.Singleton и Lifetime.Scoped. Удалось улучшить производительность методов Resolve() и корней композиции.

Всем привет, хочу рассказать о своей утилите dcw (Docker Compose Workspace) для удобного управления тестовыми окружениями на базе docker-compose.

Приложения Dotnet и Mono можно развернуть на сервере разными способами. В статье мы рассмотрим специализированные решения для хостинга dotnet приложений и предоставим инструкцию по развертыванию, написанную на конкретном примере.

При работе с современными веб-приложениями реального времени незаменима возможность отправлять события с сервера на клиент. Именно этой необходимостью продиктовано то, что за годы работы было изобретено несколько методов для этой цели, каждый с собственным набором достоинств и недостатков. Первоначально единственным вариантом был длинный опрос. Затем в качестве альтернативы появились веб-сокеты — более надёжное решение для двунаправленной коммуникации. Вслед за веб-сокетами появились события, отправляемые сервером (SSE), более простой метод, обеспечивающий однонаправленную связь от сервера к клиенту. Забегая вперёд, сейчас разрабатывается ещё и протокол WebTransport, который может тем более изменить ландшафт этой области, обеспечивая более эффективный и гибкий подход, располагающий к масштабированию. В некоторых нишевых случаях можно присмотреться и к технологии WebRTC, предназначенной для работы с событиями в направлении сервер-клиент.

В этой статье мы подробно разберём данные технологии, сравним их производительность, подчеркнём их достоинства и недостатки, а также порекомендуем, что делать в различных практических случаях, расскажем, как принимать информированные решения при создании веб-приложений реального времени. Эта статья — экстракт моего совокупного опыта, приобретённого в ходе реализации протокола репликации RxDB, обеспечивающего совместимость с различными технологиями серверной части.

В этой статье я расскажу о том, как работают побитовые операции и зачем они нужны разработчикам смарт-контрактов. Например, без них не обойтись, если нужно оптимизировать расходы на газ, а иногда эти знания полезны для понимания того, что происходит в таком (оптимизированном) коде.

Но перед тем, как перейти к побитовым операциям, необходимо понять, что такое вообще бит и байт. Так что да, это та самая школьная информатика. Не могу сказать, что в своё время углублялся в эти темы с большим энтузиазмом, и предполагаю, что я такой не один.

В статье мы рассмотрим знаковые и беззнаковые числа, прямой, обратный и дополнительный код, логические вентили, а также базовые побитовые операции и как это применяется в написании смарт-контрактов.

После публикации статьи «TOTP без смартфона» она получила много интересных и полезных комментариев. Я решил подождать, пока обсуждение затихнет и провести работу над замечаниями и высказанными мыслями.

Поскольку объём работы оказался достаточно большой, то оформил её в виде отдельной публикации-послесловия.

В ближайшем обозримом будущем ИИ будет помогать человеку во всё большем количестве отраслей. Включая, конечно, и разработку. Как известно, уже сейчас есть нейросети, которые способны оказывать неплохую помощь программистам. В этой подборке расскажем о пяти таких нейронках. Самую популярную из них, GitHub Copilot, упоминать не будем, поскольку о ней и так все и всё знают. Подробности о других пяти инструментах — под катом.

Недавно мы столкнулись с необходимостью найти библиотеку для удобной работы с базами данных. В проекте было принято решение не использовать ORM, а вместо этого применить миграции. Так как я работал только с ORM, мне, как и автору статьи, было мало знакомо понятие миграций баз данных. В поисках информации о миграциях и популярных решениях, я наткнулся на эту статью. Перевод статьи я оставил ниже. Возможно, она будет вам полезна. Буду признателен, если вы сможете поделиться библиотеками, которые используете.

В современном мире телеграм-боты стали неотъемлемой частью нашей повседневной жизни. Они стали незаменимыми в самых разнообразных задачах – от автоматизации повседневных операций до обеспечения клиентов высококачественным сервисом.

Иногда бывает так, что возникает необходимость создать собственного телеграм-бота. Меня тоже коснулся этот момент. Начав искать готовые решения, столкнулся с небольшим разочарованием: оказалось, что подходящих фреймворков нет, и придется разрабатывать бота с нуля.

Не страшно! В этой статье я поделюсь с вами всеми этапами создания собственного фреймворка для телеграм-бота с использованием C#.

Всем привет! На связи команда Практикума. Недавно мы проводили открытое алгоритмическое собеседование и теперь хотим поделиться записью. Это отличная возможность подсмотреть, каким может быть процесс, научиться на чужих ошибках или взять на примету удачные решения.

Мы попросили Самсонова Ивана рассказать о его критериях оценки кандидатов, а также поделиться советами по подготовке. На видео Иван выступал в роли тимлида, а в обычной жизни он разработчик со степенью в Computer Science и наставник курса «Алгоритмы и структуры данных».