Сегодня самым популярным акустическим оформлением как домашних, так и студийных АС заслуженно считается фазоинверторное. Применение фазоинвертора — это простой и недорогой способ получить достаточное количество низких частот без использования большой площади излучающей поверхности динамиков и шкафоподобных корпусов. Однако, как и другие рациональные решения в электроакустике, применение фазоинверторов имеет недостатки. И недостатки критично сказываются на верности воспроизведения. Среди самых вредных недостатков этих АС можно выделить бубнение, турбулентное гудение, резонансное дребезжание, уханье и прочие “злокачественные” особенности ФИ-звучания.


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

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

Допустим нам нужно скопировать всё из папки /source в папку /target.

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

Знакомьтесь, если ещё не встречались. Это синдром профессионального выгорания.

В IT-сфере около 50% специалистов испытали на себе профессиональное выгорание. Этот синдром опасен самому сотруднику, и проекту, над которым он работает, и всей компании. Более 60% выгоревших сотрудников увольняются. А затраты на найм новых, обучение и онбординг чугунной гирей ложатся на бюджет. И время — оно вообще бесценно.

Раньше burn out не воспринимали всерьёз — считалось, что это способ особо хитроумных сотрудников поменьше делать и побольше отдыхать. Постепенно в наших пампасах культура психологический гигиены в бизнесе доросла хотя бы до признания, что профессиональное выгорание и депрессия — это реальные проблемы.

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

В процессе подготовки доклада на GolangConf'2019 я использовал LaTeX. Несмотря на некоторые устаревшие вещи, немного необычное поведение, скудную или сложную документацию, я внезапно получил удовольствие. Я не стал "гуру" LaTeX, но я смог делать весьма неплохие слайды. И я хочу описать основные точки создания современной презентации на LaTeХ. Особенно это должно "зайти" айтишникам, которые по роду занятий программируют. Программировать свою презентацию — это увлекательно.

В сентябре в нашем офисе прошел большой митап по разработке на прогрессивном фреймворке vue.js. Мероприятие посетили 400 человек — это не может не радовать. В программе было 3 доклада: команда Delivery Club рассказала про технологическую сторону своей новой web-версии клиентского сайта. Ребята из MSK VUE.JS поделились опытом организации API. А ведущий разработчик Nuxt.js рассказал про основные фичи новой версии фреймворка. Под катом собрали для вас материалы с мероприятия.

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

После прочтения данной статьи:

• Вам не нужно будет отправлять 10-20 заявок в студии и фрилансерам, общаться с ними чтобы понять цены и как происходит ценообразование.
• Вы поймете почему такой большой разброс цен от 100 тыс руб до 5 млн руб за проектирование и дизайн MVP онлайн-сервиса, какие факторы на это влияют
• У каких специалистов или студий вы можете заказать разработку «под ключ» или отдельно проектирование и дизайн веб-сервиса.
• Вы сможете сами посчитать примерную стоимость и срок под свои задачи через калькулятор в таблице exel.

Для начала перейдём к некоторым соглашениям и обозначим термины.

Инструменты для автоматизации работы с операторами и повышения читабельности кода.

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

Надо ли писать код на доске? Надо ли жонглировать бинарными деревьями и знать наизусть все сложности алгоритмов, или просто разговаривать про жизнь и проекты?

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

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

Однажды мой знакомый, который на тот момент администрировал некое веб-приложение на сервере под управлением GNU/Linux, пожаловался на одного вредного администратора сервера. Тот ни в какую не хотел устанавливать htop, несмотря на все просьбы.

Я немного удивился и поинтересовался, в чём причина такого странного поведения. Если упростить, то дальнейший наш диалог получился вот таким:

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



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

Совершенствуя свой комнатный термостат, о котором писал раньше, я задался целью дополнить его беспроводным датчиком температуры для измерения температуры воздуха на улице, собрать термостат с питанием от батареек и заменить модули приемник-передатчик RF 433MHz другой парой радиомодулей с большей дальностью связи при напряжении питания не более 3В. По ходу решения этих задач вырисовалась автономная метеостанция, речь о которой пойдет ниже.

Тем, кто тут впервые, советую сразу перейти сюда. Тут — новая версия метеостанции.

Доброго Хактоберфеста, дамы и господа. Подготовил для вас подборку самых интересных находок из опенсорса за сентябрь 2019.

За полным списком новых полезных инструментов, статей и докладов можно обратиться в мой телеграм канал @OpensourceFindings (по ссылке зеркало, если не открывается оригинал).

В сегодняшнем выпуске.
Технологии внутри: Python, C, Rust, Ruby, JavaScript, Go.
Тематика: веб разработка, администрирование, инструменты разработчика.

Прошлый выпуск.

Всем привет. Это перевод статьи из книги RedHat RHCSA RHCE 7 RedHat Enterprise Linux 7 EX200 and EX300.

От себя: Надеюсь статья будет полезна не только начинающим, но и поможет более опытным администраторам упорядочить свои знания.

Итак, поехали.

23-24 сентября в Санкт-Петербурге проходила конференция Saint TeamLead Conf 2019. «Флант» принял в ней активное участие: Игорь Цупко (наш директор по неизвестному) провел митап, на котором участники разобрались в способах поиска и выявления тайных знаний внутри организации, а Сергей Гончарук (менеджер проектов) выступил с докладом «Управление распределенной командой в режиме многопроектности». По традиции, мы публикуем обзор доклада и его видео (~37 минут).

Рабочий понедельник начался со следующего диалога:

Руководитель (P): У тебя в команде не понятно, кто чем занимается.
Я (Я): Это да, у нас нет инструмента, который бы отображал общую картину работы над задачами. В гитлабе есть канбан-доски, но они только в контексте проектов и групп. Общая канбан-доска решила бы проблему.
Р: Тогда сделай доску.
Я: К утру будет готово.

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

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

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

Гибридная методология управления на основе ценностей

В этой статье мы расскажем вам об Agilean («Эджайлин») как методе создания гибридных инструментов на базе Lean и Agile и шире об Agilean как о философии управления бизнесом с плацдарма ценностей.

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

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

Для множества команд рефакторинг — это боль. Потому что если ты занимаешься рефакторингом, то не разрабатываешь основной продукт, а если не занимаешься — растет технический долг проекта. В какой-то момент команды приходят к мысли: «Давайте разграничим рефакторинг и разработку и выделим на него, например, 20% наших человеко-часов, а остальное время продолжим заниматься разработкой!» Мысль эта неплохая, вот только дело в том, что на каждые 100 разработка-часов вы никогда не получите 20 чистых часа рефакторинга. Потому что «разработка» — это не только работа с кодом.

Если мы говорим о зрелых командах, а не сжатых в материальную точку мини-коллективах на 3-5 человек, то «разработка» включает в себя еще целую массу различных активностей команды кроме написания кода. В «разработку» можно записать так нелюбимые многими митинги, работу с документацией, ведение отчетности в таск-менеджерах и так далее. Все это съедает примерно 30% от наших часов, выделенных на разработку. И как-то незаметно у нас получается, что вместо картины «80 часов кодим, 20 часов рефакторим» мы получаем неприглядную цифру в ~13 часов на, непосредственно, сам рефакторинг, потому что все остальное было поглощено другими активностями.

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

В отстойнике в пункте формирования около Ленинградского вокзала.

3 октября 2006 года с Ленинградского вокзала вышел первый состав «Мегаполиса». Даты запуска зависели от согласований, и билеты начали продавать в спешке примерно за неделю, а не за 45 дней до отправления. Никаких договорённостей с туристическими группами не было, и поезд в расписании казался просто ещё одним до Петербурга из множества. В первый рейс он ушёл с населённостью 19 % — это были случайные пассажиры. В декабре 2006 года добавили второй состав, а в мае 2007-го понадобилось добавлять вагоны: к 10 пассажирским и вагону-ресторану прицепили ещё семь, потому что пассажиров стало очень много. Запустили и второй состав по тому же маршруту.

Почему так случилось? Потому что поезд казался сказкой в 2006 году. Его делали люди, глубоко знающие железные дороги и часто путешествующие поездами. Это не люкс-класс, а максимум эффективности за земные деньги. И как следствие очень большой акцент был сделан на человеческое отношение к пассажирам.

Основателей поезда бесили отсутствие пододеяльника и необходимость пассажирам самим заправлять полки, и поэтому все полки сразу были заправлены (вслед за «Мегаполисом» так стали делать позже и в остальных поездах). Бесило то, что утром весь вагон поднимается по рубильнику от громкой музыки. Бесили необходимость сдавать бельё проводнику и очереди с этим. Бесили пугающие туалеты и ещё много всего.