Пользователь
Всем привет! Я Станислав Бушуев, Software Engineer в Semrush. В этой статье я расскажу о том, как мы столкнулись с проблемой периодического обновления Python-зависимостей, тестировали решение с полной их фиксацией, ошибались, и в итоге перешли на Poetry.
В этой статье хотелось бы поделиться мыслями о применении Нормальных Алгоритмов Маркова (далее по тексту: НАМ) в качестве основания для языка программирования.
Заранее скажу, что представленный концепт ЯП не претендует на решение каких-либо «мировых» проблем программирования, не представляет собой замену существующим инструментам, это результат моих скромных исследований в области проектирования ЯП.
Hello World, должно быть, самая часто создаваемая компьютерная программа. Уже десятилетия это первая программа, которую пишут люди, когда начинают изучение нового языка программирования.
Конечно же эта простая программа не должна иметь баги. Верно?
Статья о достаточно известной игре по угадыванию пятибуквенных слов, и о том как всегда в ней выигрывать
Если ты тоже, как и я, любишь возиться с аудио файликами, слушать, записывать, конвертировать и т.д., то эта статья для тебя. Здесь я расскажу, как можно легко выполнять различные действия с аудио из командной строки, причём делать это одинаково удобно и эффективно и на Линуксах, и на Винде. Для этого мы будем использовать программу fmedia. Она кросс-платформенная и портативная, быстрая и не требует ничего лишнего - в общем, в самый раз для тех людей, кто одержим идеей разумной минималистичности и экономии ресурсов.
В чём в принципе бонус интерфейса командной строки перед графическим?
* Во-первых, все процессы легко автоматизируются. Мы можем создать скриптик, который одним махом сконвертирует все аудио файлы в директории, или выведет список всех мета тэгов, или выполнит любую другую задачу с большим количеством файлов.
* Во-вторых, любую команду можно исполнять на удалённой машине, подключённой по SSH, например.
* К тому же, такие программы, как правило, гораздо менее требовательны к ресурсам компьютера, а это очень важно когда у нас есть только лишь старенький ноутбук. Или когда мы слушаем музыку на ноуте, работающем на батарее, и требуется продлить его время работы. Например, я на своём ноуте с Федорой могу хоть целый день слушать музыку на батарее через fmedia - реально надолго хватает заряда, главное - погасить экран.
* Нет никаких ограничений на максимальное количество файлов в активном плейлисте. Можно играть плэйлист с тысячей трэков, можно с миллионом - на скорость работы это никак не влияет.
После неудачного (с точки зрения эффективности траты времени) погружения в "Грокаем алгоритмы" по совету Яндекс Практикум и решения нескольких задач в "Бесплатный курс: подготовка к собеседованиям" от того же Яндекса решил поискать литературу на тему разбора задач. Довольно много рекомендаций указывало на книгу "Программирование: теоремы и задачи" от Александра Шень. Предыдущее издание книги можно, кстати, официально скачать с сайта издательства Московского Центра Непрерывного Математического Образования.
Сам автор характеризует книгу как справочник и задачник для преподавателя. Причем во введении и аннотации упоминает школу на порядок чаще университета. Да и формулировки многих задач намекают на школьную аудиторию. На этом стоит остановиться сразу. Речь может идти только об очень очень особой школе и очень очень особых школьниках. Например, таких, которые ходят на математический кружок мехмата МГУ, где математически доказывают выигрышную стратегию при игре в крестики-нолики. 90% материала выходят за рамки школьной программы по информатике. Да и некоторые задачи используют математический аппарат, который тоже в школьный стандарт не входит. Не стоит отметать эту книгу как что-то для маленьких и неразумных.
Бытует мнение, что простейший путь к IT лежит через тестирование. Мол, знать ничего не нужно, уметь и подавно, достаточно желания и готовности не сильно щуриться от боли и слёз, когда тебе прилетает очередной набор тест-кейсов для регрессионного тестирования.
Отчасти это даже правда, но, скорее, для ситуации, которая была на рынке лет 10 назад. Сейчас же всё обстоит несколько иначе. Причин для этого масса, и они самые разные. Если отметить ключевые, то, пожалуй, это:
Возросшие требования к тестировщикам, их знаниям и квалификации, так как всё чаще решаются задачи чуть сложнее, чем «клик-клик — и в продакшен». Работа тестировщиков становится всё более «инженерной», требует технической подкованности, специфических знаний, навыков и компетенций. Тестировщики всё чаще становится QA-инженерами (кто в теме, тот понимает разницу).
Возросшее предложение на рынке, когда толпы вчерашних «гражданских» ринулись в пучину IT, подогреваемые обилием информации: от конференций и книг до статей и курсов по тестированию ПО. Ваш покорный слуга в своё время также приложил руку к созданию пары общедоступных курсов по причине желания тиражировать базовые вещи из своей профессиональной области (посмотреть можно, например, здесь)
Поэтому сегодня всё реже можно полагаться исключительно на морально-волевые качества для входа в IT в свете возросших аппетитов рынка и обилия конференций, курсов, тренингов, литературы, статей и прочих информационных источников, которые находятся на расстоянии вытянутой руки начинающих специалистов.
Безусловно, всё больше компаний стараются выращивать специалистов у себя под крылом, осыпая счастливчиков новыми знаниями и навыками, заодно повышая лояльность к компании. Однако и в этом случае перед компаниями и их специалистами встают животрепещущие и острые вопросы…
Как не потеряться в многообразии информации, которой наполнен интернет и мир вокруг?
Что учить самим или чему учить своих бойцов?
С нарастающими скоростями и распределёнными системами всё сложнее бывает создать приложение удобным для конечного пользователя. Программы обладают кучей фич. Но выполняют ли они то, что нужно юзерам? А скорость их выполнения достаточная? А производительность при выполнении не хромает? На эти вопросы помогает ответить нагрузочное тестирование (НТ).
Меня зовут Саша, я работаю в команде тестирования Ozon Fintech и расскажу про разнообразный спектр вариантов НТ: как именно мы его применяем и какие инструменты используем. Статья будет полезна тем, кто уже что-то слышал про НТ и хочет добавить его в свой проект, но пока страшновато. Давайте разбираться!
Не так давно автор материала работал над сложной головоломкой: как пропатчить операционную систему сэмплового синтезатора 1996 года Kurzweil K2500. О путешествии автора в старый код музыкального инструмента рассказываем к старту курса по разработке на C++.
Данная статья описывает работу пакета nnhelper, предназначенного для создания и использования нейронных сетей в программах на языке Go.
Если Вы уже знакомы с машинным обучением и используете его в своей работе, то эта статья и описанные в ней примеры могут показаться вам слишком простыми. Если Вы в начале пути и хотите познакомиться с этой темой или вам хотелось бы научиться использовать нейроматрицу в ваших программах на языке Go, то вы попали точно по адресу.
Go пакет nnhelper разработан для быстрого создания нейронной сети и использовании ее в приложениях, написанных на языке Go. Для использования nnhelper не потребуется ничего дополнительного, кроме Go. Пакет nnhelper является надстройкой над пакетом gonn. И это единственная внешняя зависимость.
На прошлом уроке мы научились превращать набор особых точек, найденных специальным детектором особых точек, в граф. Там же я объяснил, зачем это вообще надо. Сегодня мы будем изучать такую область науки о компьютерном зрении, как нахождение областей интереса на изображении. Как правило, это вторая часть этапа обработки изображений (см. первый урок). И так, предположим, нам надо найти на изображении дорожный знак. Пусть мы пока ограничимся только поиском знаков «кирпич». Вот наша рабочая картинка:
Rust — хороший выбор для разработки игр. Хотя экосистема языка еще молода, с помощью FFI можно использовать готовые решения написанные на другом языке. Но написание и использование FFI может быть не тривиальной задачей, когда дело доходит до чего-то большего, чем вызов одной или двух функций.
Это руководство содержит общий обзор и конкретные приемы написания сложной Rust обёртки для звукового движка FMOD с помощью парсера pest и квази-цитирования.
Мы в Quadcode любим Golang и можем рассказать о языке и его преимуществах много интересного. Все это неспроста - не так давно мы переписали некоторые наши продукты или отдельные их модули именно на Go, чему радуемся до сих пор. Подробности самых интересных кейсов вскоре планируем раскрыть на Хабре, а пока что поделимся подборкой любимых книг, которые посвящены этому языку. Некоторые из них подходят для начинающих разработчиков, другие - для программистов с опытом. Объединяет все представленные в подборке книги одно - они могут оказаться ну очень полезными для тех, кто так или иначе связан с Go. Подборка - под катом, и, кстати, если вы уже читали какую-то из рекомендованных нами книг, расскажите о своих впечатлениях в комментариях. Поехали!
Да, кстати, еще одна ремарка - некоторые книги переведены на русский, некоторые - нет. Если перевода (пока, как хотелось бы надеяться) нет, то мы об этом скажем.
На неделе один из участников Hacker News запустил тематический тред с целью узнать, как «связать» компьютер, колонки и другую акустику в единую звуковую систему.
Мы решили рассмотреть несколько стандартов, которые используют музыканты в студиях, а также open source решения, доступные для развертки любому аудиоману.
В большинстве сильно типизированных языков поддерживается обобщенное программирование. Круг проблем, которые решаются на этих языках, один и тот же, но сами проблемы решались в разное время разными способами, и у каждого из этих способов были свои «за» и «против». Мы рассмотрим историю реализаций обобщенного программирования, чтобы вы могли распробовать его как инженер. Наилучшего подхода не существует, любой подход – это всегда компромисс, при котором одними преимуществами жертвуют ради других. Мы рассмотрим три популярных языка, обогативших нашу индустрию новыми подходами: C++, Java, C#(.Net). Для каждого из рассматриваемых языков мы ответим на следующие вопросы:
Это история о том, как я попытался писать скрипты на языке Go. Здесь мы обсудим, когда вам может понадобиться скрипт на Go, какого поведения от него следует ожидать, а также рассмотрим его возможные реализации. В этой дискуссии мы глубоко обсудим скрипты, оболочку и шебанг-строки . Наконец, обсудим решения, обеспечивающие работоспособность скриптов на Go.
Когда вы автоматизируете какую-либо задачу, например, упаковываете свое приложение для Docker, то часто сталкиваетесь с написанием shell-скриптов. У вас может быть bash-скрипт для управления процессом упаковки и другой скрипт в качестве точки входа в контейнер. По мере возрастающей сложности при упаковке меняется и ваш shell-скрипт.
Все работает хорошо.
И вот однажды shell-скрипт совершает что-то совсем неправильное.
Тогда вы осознаете свою ошибку: bash, и вообще shell-скрипты, в основном, по умолчанию не работают. Если с самого начала не проявить особую осторожность, любой shell-скрипт достигнув определенного уровня сложности почти гарантированно будет глючным... а доработка функций корректности будет довольно затруднительна.
