При использовании языка Go чувствуется нехватка хорошей библиотеки для работы с потоками данных. Имеющиеся библиотеки в основном написаны во времена до дженериков и имеют не очень удобный интерфейс.
С выходом Go 1.18 появилась возможность реализовать библиотеку потоковой обработки данных goio, вдохновлённую превосходными Scala-библиотеками cats-effect и fs2.
Если ты тоже, как и я, любишь возиться с аудио файликами, слушать, записывать, конвертировать и т.д., то эта статья для тебя. Здесь я расскажу, как можно легко выполнять различные действия с аудио из командной строки, причём делать это одинаково удобно и эффективно и на Линуксах, и на Винде. Для этого мы будем использовать программу fmedia. Она кросс-платформенная и портативная, быстрая и не требует ничего лишнего - в общем, в самый раз для тех людей, кто одержим идеей разумной минималистичности и экономии ресурсов.
В чём в принципе бонус интерфейса командной строки перед графическим?
* Во-первых, все процессы легко автоматизируются. Мы можем создать скриптик, который одним махом сконвертирует все аудио файлы в директории, или выведет список всех мета тэгов, или выполнит любую другую задачу с большим количеством файлов.
* Во-вторых, любую команду можно исполнять на удалённой машине, подключённой по SSH, например.
* К тому же, такие программы, как правило, гораздо менее требовательны к ресурсам компьютера, а это очень важно когда у нас есть только лишь старенький ноутбук. Или когда мы слушаем музыку на ноуте, работающем на батарее, и требуется продлить его время работы. Например, я на своём ноуте с Федорой могу хоть целый день слушать музыку на батарее через fmedia - реально надолго хватает заряда, главное - погасить экран.
* Нет никаких ограничений на максимальное количество файлов в активном плейлисте. Можно играть плэйлист с тысячей трэков, можно с миллионом - на скорость работы это никак не влияет.
Приглашаю вас в небольшое приключение выходного дня, в котором никто никому ничего не будет доказывать. Мы просто будем реализовывать один и тот же несложный алгоритм, разыскивающий простые числа в некотором диапазоне, на нескольких языках программирования: C, C++, Scheme и Python - и смотреть, что этим кодом могут сделать современные оптимизирующие компиляторы. В процессе приключения мы увидим, что «динамический» не означает «совсем уж медленный», и посмотрим на приёмы программирования на Scheme, что, как мне кажется, можно сравнить с путешествием на экзотический остров.
Структурирование информации — очень полезный навык. И дабы привнести некоторый порядок в этап подготовки к интервью на должность Golang разработчика (и немножко техлида) решил записывать в этой заметке в формате FAQ те вопросы, которые я задавал, задавали мне или просто были мной найдены на просторах сети вместе с ответами на них. Стоит относиться к ним как к шпаргалке (если затупишь на реальном интервью — будет где подсмотреть) и просто набору тем, которым тебе стоит уделить внимание.
Я постарался копнуть в каждый вопрос чуть глубже чем, возможно, надо бы — что бы у читателя был не только короткий ответ на вопрос, но и некоторое понимание "а почему именно так устроена та или иная штука". Более того, крайне рекомендую ознакомиться и с ссылками на источники, что будут под ответами — там вы найдете более развернутые ответы.
Да, это очень объемный пост, и вряд ли его можно вдумчиво осилить за один подход, но поместив его в закладки он, возможно, когда-то сослужит вам добрую службу (читать его можно по частям, находясь в метро или между вечными совещаниями; да и Ctrl + F никто не отменял). Ещё ему очень не хватает оглавления для удобной навигации между вопросами, но у хабраредактора нет возможности генерировать TOC (если будут запросы об этом в комментариях — сделаю его руками). Об очепятках, пожалуйста, пишите в личку.
В Go 1.18 добавлена поддержка дженериков. Это самое большое нововведение с момента первого Open Source выпуска Go. Не будем пытаться охватить все детали, затронем всё важное. Подробное описание со множеством примеров смотрите в документе с предложением по улучшению языка. Материалом делимся к старту курса по Backend-разработке на Go.
Привет меня зовут Игорь и я профессионально занимаюсь веб разработкой с 2005 года, раньше это называлось "веб-мастер", а сейчас full-stack developer.
На данный момент я tech lead в одной классной команде и иногда мне приходиться писать много текста в confluense, что бы не объяснять всё дважды и заодно приумножить knowledge base компании. Этот гайд мои "заметки на полях" в ходе исследования одного инцидента.
Ты решил «Войти в Айти» или уже работаешь в IT и хочешь найти место получше. Где же найти работу и не потратить на это несколько месяцев?
Сегодня расскажу про все основные площадки, на которых смогут найти себе работу разработчики, аналитики, продакт менеджеры, дизайнеры и другие IT-специалисты. Зайдя хотя бы на несколько из них, а не останавливаясь на одном варианте, ты в разы увеличишь свои шансы найти работу.
Привет Хабр! Пятничного тру ФП хардкора с Free Monad, Таглес Финал, Монад трансформерами, Refined Types, Smart Constructors и прочим таким вам в ленту. Хардкор сам себя в ленту не принесет так что погнали.
Гексагональная архитектура делит наш код на три основные части.
1) Primary Adapters,
2) Secondary Adapter
3) Logic aka Domain.
Рекомендации для Golang разработчиков, как использовать многоэтапную сборку, для создания более компактных Docker образов. Давайте, рассмотрим на примере, как многоэтапная сборка позволяет значительно уменьшить размер Docker образа.
Несколько дней назад мы увидели новую экспериментальную фичу под названием “проверка захвата” (capture checking), анонсированную в твите Мартина Одерски (Martin Odersky).
Эта фича является новой главой в десятилетней борьбе за добавление какой-либо формы системы эффектов в scala 3. Она имеет некоторое сходство с предложением линейных ограничений (linear constraints) для Haskell и временами жизни (lifetimes) Rust.
Найти значительное узкое место в производительности стандартной библиотеки или зрелого приложения — это редкость.
Я был удивлён, когда в top10 списке CPU-профиля hugo при сборке digitalgov.gov на первой позиции находился метод reflect.Type.MethodByName().
flat flat% sum% cum cum%
8.84s 6.28% 6.28% 57.85s 41.10% reflect.(*rtype).MethodByName
7.93s 5.63% 11.92% 8.50s 6.04% reflect.name.readVarint
7.56s 5.37% 17.29% 111.79s 79.43% reflect.Value.call
7.53s 5.35% 22.64% 23.33s 16.58% runtime.mallocgc
7.29s 5.18% 27.82% 16.10s 11.44% reflect.name.nameВ этой статье я расскажу вам о том, как так вышло и что с этим можно было бы сделать.
В этой статье мы рассмотрим, каким образом можно использовать GitHub Actions для создания конвейера непрерывной интеграции, который автоматически тестирует, проверяет и анализирует ваш код Go.
Сегодня мы будем анализировать бинарники на пару с CPU профилями, чтобы создать на их основе расширенные профили исполнения. Эти дополненные профили мы сможем использовать для оценки времени, которое программа тратит на проверки выхода за границу массивов и слайсов.
Скоро выйдет релиз 1.18 в котором появятся долгожданные дженерики. Они позволят сделать универсальные методы. Я написал пару примеров для себя. Может быть они будут интересны кому-нибудь ещё.
Одним из наиболее распространенных «лучших практик» в программировании является принцип DRY: не повторяйся. Для реализации этого принципа можно использовать множество методов: инкапсуляция, параметризация, инверсия управления и многое другое. Одним из этих методов является абстракция, и одно из основных различий между функциональным программированием (FP) и объектно-ориентированным программированием (ООП) заключается в способе применения абстракции. Обычной практикой в ООП является ограничение абстракции до строгого полезного минимума для рассматриваемой проблемы. В ООП преждевременное абстрагирование часто считается ошибкой, как и преждевременная оптимизация.
В FP, с другой стороны, абстракция, как правило, продвигается настолько далеко, насколько это возможно. Каждая проблема разбита на серию простейших возможных функций, которые затем комбинируются для построения решения проблемы. Выявление этих абстракций обычно является наиболее важной частью решения проблемы. Фактически, программисты FP часто тратят больше времени на то, чтобы найти, какую проблему им следует решить, чем на их решение. И, конечно же, обычно кажется, что эти функции одинаковы от одной проблемы к другой. Только способ их комбинирования отличается. Это причина, по которой абстракция является одним из наиболее ценных методов, используемых программистами FP.
В этой статье мы сравним, как ООП и ФП будут обрабатывать абстракцию в конкретной простой задаче: вычислении суммы целых чисел от 1 до произвольного значения n. Проблема настолько проста для решения с помощью императивного программирования, что кажется, что в этом нет ничего интересного. Вот как это можно сделать в Java:
В мире программирования существуют технологии, must have для каждого разработчика, к числу которых относится и Docker. Подразумевается, что это просто, как таблица умножения, и известно всем. О том, зачем в 2021 году в 100500й раз заводить разговор про докер — статья Сергея Кушнарева, руководителя отдела разработки ZeBrains.
С одной стороны — про него все знают. С другой — если тебя устраивают небольшие веб-проекты, особенно на какой-то конкретной CMS, то докер очень часто оказывается тем самым «первым лишним», и все сводится к инструкции «возьми готовый докер-файл, запусти в терминале docker run и будет тебе счастье». А когда понимаешь, что этого уже недостаточно — натыкаешься на статьи, написанные по тому же принципу «скачайте-запустите-получите». Кому этого мало — читайте дальше.
20 марта 2013 года на конференции PyCon 2013, Соломон Хайкс (CEO компании dotCloud) выступил с пятиминутной презентацией The future of Linux Containers. В ней широкой общественности впервые была представлена внутренняя разработка компании dotCloud под названием Docker, а спустя несколько дней ее исходный код был выложен в открытый доступ. Хотя технологии LXC и Aufs, на которых была основана первая версия Docker существовали и активно использовались уже порядка пяти лет, но именно появление Docker послужило началом стремительного роста и эволюции систем контейнеризации, что кардинально преобразило многие процессы разработки и деплоймента программного обеспечения.
Этой статьей я собираюсь начать небольшой цикл посвященный изучению развития исходного кода Docker на протяжении нескольких лет. В первой части мы посмотрим на то, что представлял собой код на момент создания git репозитория датированного январем 2013 года. Тогда исходный код Docker (за исключением тестов) состоял всего из шести файлов общим объемом ~600 строк кода, написанных на языке Go. Это больше походило на библиотеку/api, функционал которой состоял лишь в создании, удалении, запуске и остановке контейнеров. Мы разберем принцип работы и даже сможем запустить с ее помощью подготовленный контейнер.
Во второй части мы перенесемся на несколько месяцев вперед - в март 2013, когда докер был представлен на конференции PyCon. На тот момент он уже обладал практически всеми знакомыми нам функциями. А в третьей части я постараюсь рассмотреть переход Docker с LXC на собственную разработку, произошедший годом позже.