Hello world!

Представляю вашему вниманию первую часть туториала по Tokio.

• Вторая часть
• Туториал целиком

Tokio — это асинхронная среда выполнения (runtime) кода Rust. Она предоставляет строительные блоки, необходимые для разработки сетевых приложений любого размера.

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

Всем привет! В начале года я писал публикацию «Можно ли заработать на партнёрских программах хостеров в 2024 году? Пробуем посчитать» — просмотров и комментариев было немного, но в личке было немало вопросов, а я с тех пор смог заметно поправить своё финансовое положение на этих самых партнёрках. Но сегодня речь пойдёт чуть по другой, пусть и смежной теме — не так давно у меня появилась необходимость в виртуалке для тестирования разрабатываемого мной ПО, и как часто бывает, встал вопрос, у какого провайдера заказывать. В своём выборе хостеров для обзора я в первую очередь решил отталкиваться от стоимости их услуг. И в этой статье я хотел бы сравнить несколько хостингов, которые были первыми в гугле по запросу «Дешёвый VPS-сервер» — спешу поделиться с вами полученным опытом и выводами.

Приветствую всех айтишников и технарей. Я не забыл про ЯМР, я помню! Но за последнее время на глаза попалось сразу несколько статей про водородную энергетику, и каждая из них грубо задевала тонкие профессиональные струны моей души. В связи с этим я решил, что молчать дальше нету мочи, и решил немного порассуждать в слух на тему, что не так с водородной энергетикой, и что не так с её критиками. Для понимания контекста поясню: я работаю в R&D и разрабатываю электрохимические источники энергии, в том числе и водородные топливные ячейки в моем анамнезе когда-то были. Поэтому я позволю себе изложить именно свое мнение, сформировавшееся у меня за время работы в это области, с минимумом пруфов.

Всем привет!

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

ДИСКЛЕЙМЕР: это не бескорыстный акт передачи знаний с моей стороны. Я пытаюсь найти инвестиции для своего проекта и создал чат в тг, где буду постить обновления и какие-то мысли касательно его запуска. Так что если интересно, то подписывайтесь, а еще можете поделиться ссылкой с теми, у кого есть лишние бабки =)

Предыстория

Значит решил я создать сервис для одиноких мужчин, где они могут пообщаться с прекрасными дамами, aka вебкам. Соответственно встал вопрос, как организовать видеосвязь в браузере. Обычно для этого используется WebRTC, эта технология позволяет установить p2p соединение между браузерами для передачи видео, звука и прочих данных в реальном времени с минимальной задержкой. Однако была одна проблема: что делать, если приходит жалоба от пользователя, что ему показали не то (или не показали), что он хотел. Поскольку это p2p соединение напрямую между пользователями, у меня как у владельца сервиса нет возможности провалидировать жалобу. Первое, что пришло в голову это вместо WebRTC использовать MediaRecorder API для записи видео небольшими кусочками и отправки их по вебсокету через сервер, попутно сохраняя. Я набросал прототип и столкнулся с тем, что если получатель пропустил первый пакет (там где есть метаданные), то видео у него не воспроизводится. Пришлось поиском определенного набора байт в первом пакете вычленять эти самые метаданные и сохранять их отдельно для отправки первым сообщением только что подключившемуся получателю, и это даже сработало. Вторая проблема этого решения - это задержка в пару секунд, и это только в локальной сети, что приемлемо для односторонней связи, но для двусторонней уже сомнительно. И третья проблема это то что видео у получателя со временем все больше и больше отстает, и нужно регулярно проматывать видео ближе к концу. Костыльность такого решения меня не устраивала, и я решил использовать WebRTC для связи собеседников и параллельно использовать MediaRecorder для отправки записи от модели к серверу. Некоторое время оно так работало, пока я пилил другие фичи, но неэлегантность этого решения все еще не давала мне покоя, т. к. оно повышает требования к интернет соединению модели.

Когда я только знакомился с принципами SOLID, я искал понятные статьи на Хабр. При этом пришлось прочитать не одну статью, и полное понимание пришло сильно позже. Хотелось бы, чтобы новички на более простых примерах смогли почувствовать, о чем эти принципы.

Привет, Хабр!

На связи Андрей из сообщества ITMO.OpenSource. Мы считаем, что важно делать открытую науку, поэтому пишем об открытом коде, проводим митапы «Scientific Open Source» и разрабатываем научные решения с открытым кодом.

Мы убеждены, что открытая наука – это не просто код на github, но и совокупность факторов, которые позволяют этим кодом эффективно воспользоваться: запустить, модифицировать, внедрить в другие проекты. Поэтому я решил перевести популярную статью JS-разработчицы Киры Окли «Art of README». Несмотря на разницу в экосистемах (я пишу преимущественно на Python), мне кажется, многие идеи этой статьи актуальны для любого проекта на любом языке.

Примерно шесть лет назад я написал пост о том, как пишу HTTP-сервисы на Go, и сегодня я снова хочу рассказать, как пишу HTTP-сервисы.

Тот пост оказался довольно популярным и вызвал обсуждения, повлиявшие на то, как я делаю это сегодня. И спустя годы ведения подкаста Go Time, обсуждения Go в X/Twitter и поддержки подобного кода я решил, что настало время обновить информацию.

(Если вы педант и скажете, что Go не совсем 13 лет, то я отвечу, что начал писать HTTP-сервисы на Go версии .r59.)

В этом посте рассматривается широкий спектр тем, связанных с созданием сервисов на Go

Мы, разработчики ПО, пользуемся git каждый день, однако большинство из нас применяет только самые основные команды, например, add, commit, push и pull, как будто на дворе по-прежнему 2005 год.

С тех пор в Git появилось множество фич, пользование которыми может сильно упросить вашу жизнь. Так давайте исследуем некоторые из недавно добавленных современных команд git, о которых вам стоит знать.

Всем привет, меня зовут Артемий, я работаю старшим Android-разработчиком в команде пользовательского профиля в RuStore. Мой опыт в индустрии уже 8 лет. За это время я успел поработать в разных проектах и компаниях. У меня был опыт работы в проекте, в котором было свыше 300 модулей и больше 60 Android-разработчиков. Такие условия заставляют задуматься о масштабируемости на принципиально ином уровне.

Сегодня я расскажу о способах обеспечения масштабируемости проекта и как этому может навредить неправильное восприятие Чистой Архитектуры (далее — ЧА). Предупреждаю сразу, это лонгрид в двух частях!

Как-то я был на встрече, где участники громко спорили и не соглашались друг с другом. Причем все говорили об одном и том же, только с разных сторон. И тут один из участников взял маркер и начал рисовать на флипчарте квадратики, стрелочки, человечков. В какой-то момент спорившие обратили внимание на рисунки и начали подсказывать, что добавить, а где стрелочка не так идет. Всего через десять минут оживленный спор превратился в конструктивный диалог, который разворачивался вокруг изображения на флипчарте. Так я впервые столкнулся с визуальной фасилитацией.

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

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

- Сможете изготовить такую деталь?
- Да, но скругления нужно заменить на фаски.

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

У одного из клиентов нашей системы мониторинга PostgreSQL серверов возникла проблема сильного замедления запросов при запуске базы в Docker. В этой статье расскажем о возможных последствиях использования PostgreSQL в Docker с конфигурацией по умолчанию.

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

Занимаясь "улучшительством" отдельно взятых элементов, бизнес рискует выкинуть из стенных часов с кукушкой стрелки: с точки зрения механизма они делают бесполезную работу, создавая только избыточное давление. А потом уберут и кукушку, потому что она из-за изменения баланса начнёт петь невовремя. Оставшиеся элементы между собой будут весьма гармонично взаимодействовать, только для конечного пользователя от этого не будет никакой пользы.

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

Бывают ситуации, когда жизненные обстоятельства не позволяют использовать ChatGPT и приходится разворачивать LLM локально. Там можно остаться и без AI, а этого мужики точно не поймут. Есть ли какие-то способы решения этой проблемы?

Если у вас такая ситуация – можете выдохнуть, решение есть.