Несколько лет назад я начал добавлять Go в свой арсенал языков (будучи на тот момент Java разработчиком). Мне было очень непривычно. Более того, я принял язык не с первой попытки. Причём пришлось принять его больше из-за сложившихся обстоятельств, чем по собственному желанию.

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

Уточню: статья ориентирована больше на тех, кто планирует перейти в Go, чем для опытных разработчиков.

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

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

Netflix продолжает расширять бизнес и диверсифицироваться в различных направлениях, вроде доставки видео по запросу и гейминга. В результате всё важнее становятся технологии, обеспечивающие загрузку временных (темпоральных) данных в системы компании и их хранение. Речь идёт об огромных объёмах данных, измеряемых петабайтами. А задержки доступа к этим данным должны укладываться в миллисекунду. В предыдущих материалах мы рассказывали о нашем слое абстракции для хранения данных типа «ключ-значение», и о платформе, реализующий возможности шлюза данных. И то и другое — это неотъемлемые части подсистемы, отвечающей в Netflix за работу с данными. Система хранения данных типа «ключ-значение» — это гибкое и хорошо масштабируемое решение для работы со структурированными данными соответствующего формата. А шлюз данных — это платформа, которая даёт компании базовую инфраструктуру, обеспечивающую защиту, настройку, развёртывание компонентов, ориентированных на работу с данными.

TLDR. Я примерно год создавал курс из 141 урока. Курс получился хороший, все кто проходят рады и пишут положительные отзывы. Я пытался его продавать, в лучшем случае у меня получалось отбивать рекламу в ноль. Короче, я хороший разработчик, я хорошо доношу материал, но я плохой маркетолог. Все эти таргреты, ретаргеты, воронки, шморонки — тоска унылая. Мне гораздо веселее и понятнее заработать на создании и запуске IT-продуктов, чему я и учу в этом учебнике. Так что пишу эту статью, чтобы сообщить вам о существовании моего курса и предложить всем желающим абсолютно бесплатно получить от него пользу 🙂

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

Сегодня я хочу поделиться своими знаниями о паттерне, который может значительно упростить работу, если ты пишешь на Go. Речь пойдет о функциональных опциях. Поверь, как только ты разберешься c этим, твой код станет немного гибче и проще.

Привет, Хабр! С вами снова Матвей Мочалов из cdnnow!, и в этом посте мы не будем разбираться с FFmpeg - в этот раз наша рубрика «Эээээксперименты!» будет затрагивать объектные хранилища. Разберёмся, чем S3 отличается от S3, а также почему не всё то S3, что называется S3. А заодно эксперимента ради сделаем своё собственное простенькое объектное хранилище на любимом языке всех DevOps и SRE-инженеров – Go.

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

Эта статья является неким сборником многих статей про все, что связано с параллелизмом в Go, например: горутины, каналы, select и многое другое.

Я хотел углубиться в тему горутин с параллелизмом и, слушая на фоне "The Doors", поглощал информацию и выделял интересные мысли из статей

Надеюсь, Вы найдете для себя то, что искали.

Большие языковые модели (LLM, Large Language Models) стали незаменимыми инструментами для разработчиков и исследователей. С их помощью можно решать разнообразные задачи.. Однако использование таких моделей часто связано с зависимостью от внешних сервисов, что накладывает определённые ограничения. Локальное развертывание LLM позволяет сохранить контроль над данными и гибко настроить модель под конкретные нужды, используя при этом преимущества локальной инфраструктуры.

В этой статье я бы хотел рассказать о преимуществах локального развертывания LLM и рассмотрим несколько open-source решений, которые можно использовать для этой цели.

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

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

Тут был диспут пару дней назад на фейсбуке с социологом Алексеем Рощиным, в котором он сделал совершенно безумное заявление "в России нет и не может быть чипов, а если что-то и есть, то оно на два поколения устарело". Понятно, что в России чипы есть, например микроконтроллер MIK32 АМУР, выпущенный в Зеленограде на основе процессорного ядра от питерской компании Syntacore. Причем если сравнивать Амур его с STM32 U0 2024 года (низкопотребляющий микроконтроллер от мирового лидера на 90 нм, 56 MHz), то нельзя сказать что российское "на два поколения устарело". У микроконтроллеров крутость не в нанометрах (чип на 3 нм все равно не выдержит рядом с горячим автомобильным двигателем), а в системных и микроархитектурных решениях (трюки для экономии динамического энергопотребления, эффективный DMA, даже AI расширения в стиле ARM Ethos-U55).

Учитывая, что Рощин - человек не безумный, я попытался понять, что он имеет в виду, и кажется понял.

// гофер пытается найти логику среди обработки ошибок
+-------+-------+-------+-------+-------+-------+
|       |  err  |       |  err  |       |  err  |
|  ,_,,,        |       |       |       |       |
| (◉ _ ◉)       |       |       |       |       |
|  /)  (\               |       |       |       |
|  ""  ""               |       |       |       |
+       +-------+       +-------+       +-------+
|       |  err          |  err  |       |  err  |
|       |               |       |       |       |
|       |               |       |       |       |
+-------+       +-------+       +-------+       +
|  err  |               |  err                  |
|       |               |                       |
|       |               |                       |
+       +-------+       +       +-------+       +
|       |  err  |               |  err  | logic |
|       |       |               |       |       |
|       |       |               |       |       |
+-------+-------+-------+-------+-------+-------+

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

Но сорян, к бесконечным if err != nil я до конца привыкнуть так и не смог.

Да-да, я знаю все аргументы: явное лучше неявного, язык Go многословен, зато понятен, и всё такое. Но, блин, на мой взгляд Го-вэй Го-вэю рознь.

Приветствую, в прошлой статье мы разбирали определение bytes.Buffer изнутри. Теперь хочется обратить внимание на сам пакет bytes. Что за ним скрывается? Каждому разработчику приходилось использовать его будь то в production или локальной разработке. Это достаточно мощный по своим меркам пакет, который предоставляет нам функции для работы с байтами.

Привет! Меня зовут Александр Щербаков. Я DevOps команд страхования в Банки.ру. На своём карьерном пути я успел поработать эникейщиком, системным администратором и, наконец, DevOps‑инженером с несколькими командами разработки. Как и любой инженер, я стремлюсь постоянно совершенствоваться: получать новые знания, изучать как устоявшиеся, так и только появившиеся технологии.

И здесь сразу появляется главная проблема — для развития DevOps нужна среда, где можно запускать ПО для исследования. Разработчикам проще: открыл документацию, скачал IDE, начал пробовать и изучать новую технологию. А вот DevOps‑инженеру одной только IDE будет мало, так как часть его работы как минимум завязана на Linux серверах. Поэтому важно не просто знать, как использовать готовые решения, но и понимать, как они функционируют на уровне инфраструктуры.

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

У меня есть опыт приобретения и развёртки домашнего сервера, поэтому я решил написать серию статей, в которых расскажу о подготовке и поэтапной установке сервера.

Десять лет назад я писал пару статей - Как загрузить последний Office с сайта Microsoft без всякого App-V / Хабр (habr.com) и Как загрузить Microsoft Office 16 с сайта Microsoft / Хабр (habr.com), при помощи на тот момент еще мало кому известным Office Deployment Tool.

Время бежит стремительно, за Office 2016 выходит Office 2019, Office 2021, и вот сейчас подошло время для Office 2024. Что ж, посмотрим, что поменялось в плане загрузки, установки и активации продукта за десять лет.

Для начала о версиях и изданиях Microsoft Office. Чтобы не быть слишком дотошным в описании, скажу коротко самое главное, - с годами линейка Office развивается, существуют разные подписки и планы обновления, - новые функции появляются в новых версиях, для старых версий выходят исправления ошибок и заплатки к найденным уязвимостям.

Microsoft давно перешел на систему распространения продуктов семейства Office по разным, так называемым, "каналам" (channels), в зависимости от того как часто вы хотите получать нововведения и обновления.

Ключевым отличием в текущей загрузке и установке Office от того, что было актуально во времена Office 2016, является то, что вы должны определить, каким каналом распространения вы собираетесь пользоваться, - то есть с какого канала собираетесь устанвливать сам продукт. Тем, кто хотел бы подробно изучить разные каналы распространения я предложу почитать первоисточник - Обновления Office - Office release notes | Microsoft Learn. Остальным кратко резюмирую - Microsoft сейчас предпочитает всем продать подписку на Microsoft 365 (то, что ранее называлось Office 365), с регулярно обновляемыми возможностями в течении так называемой Современной политики жизненного цикла. По этой же современной политике распространяется пользовательские (коробочные, ретейл) версии Office 2021. Office 2021, например, поддерживается лишь до 13 октября 2026. А более старые версии следуют, так называемой политике фиксированного жизненного цикла, в рамках которой Office 2016 и Office 2019 поддерживаются лишь до 14 октября 2025. В целом, они не перестанут работать после, однако, перестанут обновляться. И у тех из вас, кто пользуется почтовыми сервисами на базе Microsoft Outlook.com или Office365, а возможно и пользователям Microsoft Exchange, с обновлениями выпущенными после 14 октября 2025 уже пора призадуматься об обновлении.

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

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

А чтобы картинка не получилась однобокой, сделаем мы это вместе: точку зрения команды бэкенда расскажет Наташа, системный аналитик (SA) компании Интаро, взглядом фронтенда поделится Лиза, аналитик (BA) компании Surf.

Поделюсь как начал писать приложение для интернет-магазина на монолите, затем перешёл на микросервисы.

Регистрация программ для ЭВМ и баз данных нужна не только для получения красивого свидетельства, но и для того, чтобы открыть конкретные возможности для бизнеса. Зарегистрировать ПО можно в двух государственных органах России. 

Меня зовут Юрий Горбачев. Я руковожу патентным бюро «Лирейт». В этой статье на конкретных примерах из практики я разберу причины регистрации в каждом ведомстве и преимущества, которые получают предприниматели и разработчики. 

Утилита Tcpdump знакома любому сетевому администратору, с ее помощью мы собираем трафик для последующего анализа. Типичная история – собираем траффик, приходящий на нужный интерфейс и затем уже анализируем его Wireshark. Подход практичный, ведь Wireshark Действительно очень мощный и полезный инструмент и о нем мы напишем еще не одну статью, но сегодня речь пойдет про Tcpdump. Не секрет, что утилита Tcpdump не интерпретирует протоколы прикладного уровня, ограничиваясь работой с транспортным уровнем. Однако, в этой статье мы рассмотрим различные варианты использования утилиты Tcpdump для более глубокой фильтрации трафика.

Итак, Tcpdump - утилита UNIX, позволяющая перехватывать и анализировать сетевой трафик, проходящий или приходящий через компьютер, на котором запущена данная программа.

Четыре года назад ИТ-эксперт Чип Хуэн* проанализировала экосистему ML с открытым исходным кодом. С тех пор многое изменилось, и она вернулась к изучению темы, на этот раз сосредоточившись исключительно на стеке вокруг базовых моделей.

О результатах исследования читайте под катом.

*Обращаем ваше внимание, что позиция автора может не всегда совпадать с мнением МойОфис.