User
Одним из самых захватывающих объявлений на Google I/O в этом году стала официальная поддержка Kotlin для разработки под Android.
Котлин на самом деле не новый язык, ему уже >5 лет и он довольно зрелый. Здесь вы можете получить более подробную информацию о языке
Я планирую поделиться некоторыми «практиками» использования Kotlin в разработке Android.
Представлен выпуск проекта netutils-linux 2.5.0, набора утилит для мониторинга и тюнинга производительности сетевого стека Linux. Всё написано на Python (поддерживаются python 2.6+ и 3.4+) и доступно под MIT-лицензией.
Цель проекта — упростить и унифицировать процесс тюнинга сетевого стека и сетевых карт, снизив необходимость разбираться в устройстве сетевого стека для сисадминов и освободить их головы от рутинных вычислений и написания с нуля кучи одинаковых bash-скриптов.
Рекомендации для использования — наличие канала с 200+ Мбит/с, обрабатываемого Linux-based машиной, и требований к минимизации задержек и потерь.
С прошлого (и первого) публичного релиза было исправлено несколько неприятных ошибок, связанных с совместимостью с архитектурами, дистрибутивами Linux, версиями Python и зависимостей проекта, приводивших к невозможностям запуска некоторых утилит.
Программисты проверяют идеи для сайтов на площадках: codepen, jsbin, jsfiddle, cssdesk. Потому что там они мгновенно видят результат написанного кода и могут показать его другим.
Codepen — одна из самых популярных. Там более 500 тыс. готовых решений. Из них половина — хлам: неэффективный код, не работают на планшетах и телефонах, не поддерживают все популярные браузеры. Надо потратить много часов на поиск идеи, которую можно использовать на своем сайте.
Я решил делать подборки полезных решений с codepen. Первую уже выпускал на хабре «Обзор многоуровневых меню». Теперь вторая — «Обзор анимации для страниц загрузки сайта».
Подборку разделил на 3 статьи.
Сетевой стек Linux по умолчанию замечательно работает на десктопах. На серверах с нагрузкой чуть выше средней уже приходится разбираться как всё нужно правильно настраивать. На моей текущей работе этим приходится заниматься едва ли не в промышленных масштабах, так что без автоматизации никуда – объяснять каждому коллеге что и как устроено долго, а заставлять людей читать ≈300 страниц английского текста, перемешанного с кодом на C… Можно и нужно, но результаты будут не через час и не через день. Поэтому я попробовал накидать набор утилит для тюнинга сетевого стека и руководство по их использованию, не уходящее в специфические детали определённых задач, которое при этом остаётся достаточно компактным для того, чтобы его можно было прочитать меньше чем за час и вынести из него хоть какую-то пользу.
Как вы уже могли заметить мы в команде Aerokube продолжаем упрощать жизнь в инфраструктуре тестирования. Сейчас мы усиленно работаем над удобными инструментами для, браузерного тестирования на основе Selenium. Одним из инструментов, о котором я уже рассказывал раньше, является Selenoid. Selenoid — это легковесный сервер, запускающий изолированные браузеры в Docker контейнерах. В предыдущих статьях (раз, два) я описал два возможных сценария использования Selenoid — работа с Docker и использование исполняемых файлов веб-драйверов в операционных системах, где отсутствует поддержка Docker. Сегодня я расскажу о новых возможностях, которые могут помочь в отладке браузерных тестов.
Долго меня мучала идея из старенького RPI сделать принт-сервер (удаленная печать и сканирование) и наконец я до этого добрался.
Исходим из того, что у нас есть набор из RPI, флешки с Raspbian, Wi-Fi адаптера, принтера HP LaserJet Pro 1102, МФУ HP Deskjet F2180 и usb-хаба. Основная машина (ББ), которая будет использовать принт-сервер живет на Linux (впрочем, отличия в использовании для Windows будут минимальны).
Не секрет, что у многих из нас остался 1 Тб свободного места на MRU-Облаке со времён его бета-теста. Объём приличный по нынешним меркам — но что с ним делать? Фотографии и своё видео туда просто так заливать не очень хочется — взломы аккаунтов случаются нередко, да и в любом случае — облако это облако, и нельзя сбрасывать со счетов тот простой факт, что любое облачное хранилище принадлежит коммерческой компании, в интересах которой использовать его для собственной выгоды. А значит, нужен дополнительный слой защиты, например, EncFS. Полистаем хабр и гитхаб, вроде бы имеется решение о шифровании данных в своём облаке. Но есть неочевидное, но весьма важное неудобство, о котором в исходной статье не упоминается — для того, чтобы синхронизироваться, нужно локально хранить 600Гб шифрованных фотографий. Для скромных локальных хранилищ, в которых и нешифрованные 600Гб фотографий едва умещаются, это слишком много.
