До недавнего времени во всех проектах фронта разработчики Dodo Pizza Engineering использовали tslint – полезный инструмент, который подсказывает, когда ты накосячил в коде допустил неточность, помогает поддерживать код в одном стиле и сам исправляет многие замечания. Но тут tslint взял и умер. Под катом я расскажу, почему так вышло, как перестать лить слёзы по умершему и перейти на инструмент eslint, а также покажу кое-что очень интимное.

TL;DR В статье описывается мой опыт постройки стола c нуля из фанеры. От проектирования до сборки.

Я очень долго страдал от плохих столов. Все они неудобные, плохого качества, маленькие и, самое главное, ШАТКИЕ. Более-менее приличные столы стоили тысячи долларов. В итоге я решил изготовить стол самостоятельно.

Основные требования к столу:

• Устойчивость! Предметы на столе не должны трястись, если резко положить руки на стол или оттолкнуться от него. Мой стол весит ~120кг. С его края можно делать сальтухи, при этом на другом конце паять SMD компоненты.
• Ширина и глубина столешницы. Столы шириной 60 см — это унижение. Мне нужно иметь запас по глубине, чтобы можно было отодвинуть ноутбук вперед, и при этом получить достаточное рабочее пространство.
• Вместительность. Мне нужны полки, чтобы разместить там оборудование: паяльники, лабораторный блок питания, осциллограф, аудио усилитель и т.д. При этом полки должны быть так же устойчивы, как и стол.
• Цена. Я не готов выложить за стол несколько тысяч долларов. Мой стол обошелся в ~$300 с учётом покупки всего инструмента для сборки и покраски.

Устройства компании Mikrotik стали широко распространены из-за своей цены по отношению к функционалу. Но и ошибки в программном обеспечении никто не отменял. И на этот раз вылез серьёзный баг.

25 марта один из пользователей форума Mikrotik сообщил об обнаружении подозрительной активности маршрутизаторов mikrotik с применением портов telnet (TCP port 23), TR-069 (TCP port 7547) и WINBOX (TCP 8291).

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

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

Анализатор спектра тока

Представьте себе ТЭЦ с турбинами, скажем, 50–60-х годов выпуска. Это примерно половина мощностей нашей страны. Там есть огромные насосы с электродвигателями и такие же огромные генераторы, которые тоже суть электродвигатели, только «перевёрнутые». У них нет встроенной телеметрии, и диагностируются они методами последовательных обходов. Это было нормальным на конец 70-х, но не сегодня.

На ТЭЦ, на крупных буровых, на насосных станциях и во множестве других мест, где отказ электродвигателя или генератора обходится очень дорого, как правило, есть специальные люди, которые имеют огромный опыт обслуживания конкретно этого экземпляра оборудования. Например, там может быть дедушка, который по звуку запуска определяет состояние движка. Или мужик-нос, который умеет обнюхивать насос так, что чувствует даже малейшие утечки масла.

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

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

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

Я открою этот цикл статьёй о Theano — библиотеке, которая используется для разработки систем машинного обучения как сама по себе, так и в качестве вычислительного бекэнда для более высокоуровневых библиотек, например, Lasagne, Keras или Blocks.

Theano разрабатывается с 2007 года главным образом группой MILA из Университета Монреаля и названа в честь древнегреческой женщины-философа и математика Феано (предположительно изображена на картинке). Основными принципами являются: интеграция с numpy, прозрачное использование различных вычислительных устройств (главным образом GPU), динамическая генерация оптимизированного С-кода.

О чём это я?

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

(Здесь и далее будет говориться о немного специфичной и оптимизированной настройке LTSP и поднятии на его основе кластера серверов).

«Чтение и личный опыт формируют мировоззрение. И даже если вы не помните самый момент получения опыта или содержания книги, то их влияние на ваше представление о мире непременно остается в Вас. Ваш разум похож на скомпилированную программу без исходного кода — он работает, но не ясно как.»

— Пол Грэм, основатель Y Combinator, программист, инвестор, эссеист

• Предыдущая подборка от экспертов YC — Y Combinator рекомендует: лучшие 15 книг в 2015 году, на которые стоит обратить внимание.
• Пол Грэм делится, почему важно читать книги — «Как знать (How You Know)»

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

Dokku — это мини-Heroku, сделанный на базе Docker и состоящий из менее чем 100 строк на Bash.

После установки Вы сможете публиковать свои приложения простым git push. Каждое приложение будет запущено в изолированном контейнере. В конечном итоге у Вас будет своя Heroku-подобная платформа.

Часто мониторинг сетевой подсистемы операционной системы заканчивается на счетчиках пакетов, октетов и ошибок сетевых интерфейсах. Но это только 2й уровень модели OSI!
С одной стороны большинство проблем с сетью возникают как раз на физическом и канальном уровнях, но с другой стороны приложения, работающие с сетью оперируют на уровне TCP сессий и не видят, что происходит на более низких уровнях.

Я расскажу, как достаточно простые метрики TCP/IP стека могут помочь разобраться с различными проблемами в распределенных системах.

В комментариях к одной из статей блога прозвучал вопрос о покупках восстановленной техники за рубежом. Спрашивали — отвечаем.

Вопрос эффективного управления своим рабочим временем актуален для любого разработчика. Для технического директора — тем более. CTO одного из британских стартапов, рассказал о самописном решении, позволявшем ему анализировать собственную продуктивность на протяжении более чем 1 года. Далее предлагаем вашему вниманию непосредственно текст публикации, переведенной на русский язык и адаптированной силами редакторов блокчейн-стартапа Wirex.

Я — кофаундер и CTO успешного SaaS стартапа Overleaf. Наш офис расположен в Лондоне. С августа 2014 года по декабрь 2015 я вручную отслеживал свое рабочее время минута за минутой и анализировал данные в R.

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

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

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

Перед тем, как погружаться в пучины бинарных дампов, давайте прикинем, как работают большинство движков визуальных новелл. Визуальная новелла сама по себе состоит из текста (реплик героев, диалогов, промежуточного повествования), графики и звуков. Для того, чтобы ее воспроизвести пользователю, явно нужно свести все это воедино с помощью какого-то управляющего воздействия. В теории можно было бы зашить это все прямо в exe-файл, но в 99% случаев (ладно, вру, в 100% виденных лично мной) так все-таки не делают, а хранят такие инструкции отдельно в виде отдельной программы-скрипта. Как правило, скрипт пишется на особенном языке программирования (специфичном для движка), который выглядит как-то так:

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

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



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

Поводом для этого поста можете считать то, что мы добавили в приложения Яндекс.Музыки возможность слушать треки в высоком качестве (320kbps). А можете не считать. Итак.

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

Память, медленная-медленная память

В начале 1980-х время, необходимое для получения данных из ОЗУ и время, необходимое для произведения вычислений с этими данными, были примерно одинаковым. Можно было использовать алгоритм, который случайно двигался по динамической памяти, собирая и обрабатывая данные. С тех пор процессоры стали производить вычисления в разы быстрее, от 100 до 1000 раз, чем получать данные из ОЗУ. Это значит, что пока процессор ждет данных из памяти, он простаивает сотни циклов, ничего не делая. Конечно, это было бы совсем глупо, поэтому современные процессоры содержат несколько уровней встроенного кэша. Каждый раз когда вы запрашиваете один фрагмент данных из памяти, дополнительные прилегающие фрагменты памяти будут записаны в кэш процессора. В итоге, при последовательном проходе по памяти можно получать к ней доступ почти настолько же быстро, насколько процессор может обрабатывать информацию, потому что куски памяти будут постоянно записываться в кэш L1. Если же двигаться по случайным адресам памяти, то зачастую кэш использовать не получится, и производительность может сильно пострадать. Если хотите узнать больше, то доклад Майка Актона на CppCon — это отличная отправная точка (и отлично проведенное время).

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

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

Дорогие коллеги, конечно же это ваше дело, как и что вы пишете в логи своей программы, однако задуматься только ли для себя вы это делаете, все же стоит… Возможно, кроме вас, на эту строчку сейчас с отчаяньем смотрит какой-нибудь пользователь вашей программы, а то и умный до нельзя, но матерящийся почем зря, бот.

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

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

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

Пара вводных слов
Всем доброго времени суток, меня зовут Туманов Дима. Сейчас я работаю в компании Rambler&Co и отвечаю за тестирование на проектах Афиши. В рамках данной статьи я развею несколько мифов об IT и тестировании в частности. Кроме того, приведу примеры из жизни как “не зная ничего” стать Junior QA Engineer в крупной компании.

Начало пути
Проработав почти два года в одной “мирной” госкорпорации в должности “ненастоящего инженера”, я осознал, что развитие остановилось. Я мог сидеть на одном месте и почти ничего не делать. В конечном итоге мои знания бы совсем отстали от реальной действительности и я бы стал невостребованным на рынке. В этот момент я принял решение о смене места и сути своей работы.

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

«Очень нравится сайт, потому что он не боится нарушать одно из первых правил шрифта – не использовать слишком много разных гарнитур. Используется четыре шрифта, два из семейства sans-serif и два из serif — Galaxie Copernicus, Interstate, Harriet и Nimbus Sans. Основной момент такого дизайна – последовательность, и сайт Бетани Хек последовательно использует каждый из шрифтов для своей цели.»
— Джеремия Шоаф, Typewolf

Расцениваю это, как вызов. Спасибо, Джеремия!

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



Так почему же у нас есть правила насчёт количества используемых гарнитур?

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



Будем честными, большинство программистов не любят писать код на собеседовании. Некоторые даже угрожают уйти из профессии по этой причине. Но в ближайшее время ничего не изменится. Так что если вы действительно хотите получить работу, то придётся понять, как можно добиться успеха на этих собеседованиях. Я помогу вам. Мы изучим процесс, и я объясню, что именно я хочу добиться от собеседования, так что у вас сложится довольно чёткое представление, как его пройти.