Если вы не изучали JavaScript с самого начала, то осваивать его современную версию сложно. Экосистема быстро растёт и меняется, так что трудно разобраться с проблемами, для решения которых придуманы разные инструменты. Я начал программировать в 1998-м, но начал понимать JavaScript только в 2014-м. Помню, как просматривал Browserify и смотрел на его слоган:

Browserify позволяет делать require («модули») в браузере, объединяя все ваши зависимости

Я не понял ни слова из предложения и стал разбираться, как это может помочь мне как разработчику.

Цель статьи — рассказать о контексте, в котором инструменты в JavaScript развивались вплоть до 2017-го. Начнём с самого начала и будем делать сайт, как это делали бы динозавры — безо всяких инструментов, на чистом HTML и JavaScript. Постепенно станем вводить разные инструменты, поочерёдно рассматривая решаемые ими проблемы. Благодаря историческому контексту вы сможете адаптироваться к постоянно меняющемуся ландшафту JavaScript и понять его.

Эта статья также есть на английском.

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

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

Под катом — дюжина приемов в командной строке — из личного опыта.

Всем привет. Расскажу немного про свою последнюю междуделку — доработку домофона WiFi-модулем NodeMCU. Заранее прошу прощения за выбор модуля — всех уже, наверное, достала эта ESP’шка…

Конечно, работу ClusterM с его автоответчиком никому не переплюнуть, но такой функционал я считаю излишним. Мне, с рождением дочки, лишь понадобилось бесшумно открывать домофон гостям, чтобы не стоять у трубки и не ждать входящего звонка, который наверняка разбудит малую. Да и себе иногда легче открыть дверь с телефона, нежели лезть за ключами и прикладывать таблетку туда-сюда, чтобы она сработала (у меня очень сильно тупит панель в подъезде). Проект получился небольшой, так что в статье тоже не так много букв, зато есть фотографии.

Привет, Хабр! Представляю вашему вниманию перевод статьи Ideal OS: Rebooting the Desktop Operating System Experience автора Josh Marinacci.

TL;DR: В этой статье Я хочу показать что:

• современные десктопные операционные системы не такие уж и современные. Это тормознутое поделие, обрюзгшее невообразимым множеством слоёв легаси-хлама, которое всё ещё функционирует лишь благодаря закону Мура.
• инновации в десктопных операционных системах остановились 15 лет назад и все ведущие игроки вряд ли захотят снова в них вложиться
• мы можем и нам следует начать всё с нуля, выучив уроки прошлого.

Intro

Основам git мне пришлось научиться на своем первом месте работы (около трех лет назад).
С тех пор я считал, что для полноценной работы нужно запомнить всего-лишь несколько команд:

• git add <path>
• git commit
• git checkout <path/branch>
• git checkout -b <new branch>

И дополнительно:

• git push/pull
• git merge <branch>
• git rebase master (а что, можно еще и на другие ветки ребейзить? О_о)

В принципе, я и сейчас во многом так считаю, но со временем волей-неволей начинаешь узнавать интересные трюки.

Введение

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

Скрипт позволяет одной командой создать работающий сервер и создать файлы конфигурации для клиентов в unified формате (то есть с сертификатами, включёнными в файл конфигурации). Кстати, эти файлы подходят для мобильных устройств.

Скрипт создавался для машин с CentOS 7.x или Ubuntu Server 17.x, использование на Ubuntu 16.x. возможно, но там OpenVPN 2.3.x в репозиториях. При необходимости можно добавить другие дистрибутивы, но обычно при покупке VPS можно выбрать систему и это не так важно.

Недавно мне довелось побывать на встрече участников проекта FreeCodeCamp в Сан-Франциско. Если кто не знает, Free Code Camp — это сообщество, нацеленное на изучение JavaScript и веб-программирования. Там один человек, который готовился к собеседованиям на позицию фронтенд-разработчика, попросил меня подсказать, какие вопросы по JavaScript стоит проработать. Я немного погуглил, но не смог найти подходящего списка вопросов, на который я бы мог дать ссылку и сказать: «Разбери эти вопросы и работа твоя». Некоторые списки были близки к тому, что мне хотелось найти, некоторые выглядели очень уж простыми, но все они были либо неполными, либо содержали вопросы, которые вряд ли кто станет задавать на реальном собеседовании.

Научно-исследовательский центр Rocket Lab. Фото: Ian Teh для Bloomberg Businessweek

Остались в прошлом времена, когда космос и ракетостроение были государственным делом. Наступает эпоха частной космонавтики, и она наступает очень быстро. Илон Маск запускает ракеты почти каждый день и сажает их обратно. И SpaceX — далеко не единственная частная фирма, которая выводит спутники на орбиту. Сейчас в мире около 10 компаний работают над изготовлением небольших ракет для запуска мини-спутников.

Показателен пример начинающей компании Rocket Lab, которую основал новозеландский предприниматель и инженер-самоучка Питер Бек (Peter Beck). Созданная им ракета может кардинально снизить стоимость вывода на орбиту маленьких спутников CubeSat, пишет Bloobmerg. Предприниматель обещает брать всего $5 млн за запуск — это гораздо дешевле, чем $60 млн у SpaceX, не говоря уже о других конкурентах.

Прошлая неделя подарила два «вкусных» релиза из Open Source-мира контейнеров: практически одновременно обновились Docker (версия 17.06) и Kubernetes (версия 1.7). Какие возможности они принесли? В статье представлена информация из анонсов и release notes этих релизов с небольшими уточнениями по некоторым из ключевых изменений.

Чтобы отслеживать состояние работающих приложений, необходимо проводить их постоянный мониторинг. А если приложения выполняются в таком хорошо масштабируемом окружении, как Docker Swarm, то потребуется также и хорошо масштабируемый инструмент мониторинга. В этой статье говорится о настройке именно такого инструмента.

В процессе работы мы установим агенты cAdvisor на каждой ноде для сбора метрик хоста и контейнеров. Метрики будут сохраняться в InfluxDB. Для построения графиков на основе этих метрик воспользуемся Grafana. Эти инструменты распространяются с открытым исходным кодом и могут быть развернуты в виде контейнеров.

Для построения кластера мы будем использовать Docker Swarm Mode и развернем необходимые сервисы в виде стека. Это позволит организовать динамическую систему мониторинга, которая способна автоматически начинать мониторинг новых нод по мере их добавления в рой (swarm). Файлы проекта можно найти здесь.

Представляю вам перевод моей статьи на Medium.com.

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

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

Всем привет. Решил я закрепить полученный результат написав статью. А результат этот — это объединение нескольких WiFi точек доступа в сеть в одну неразрывную сеть, ещё её называют бесшовную. Смысл сего действия состоял в том, что моя «локальная» домашняя сеть разрослась до нескольких WiFi точек по причине её (сети) большой площади и невозможности достичь надлежащего качества всего одной точкой.

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

Итак, что дано:

• Есть большой репозиторий, содержащий множество папок. Каждая папка – это отдельный проект.

Что необходимо сделать:

• Одну из папок перенести в отдельный репозиторий с сохранением ее истории коммитов.

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

Я использовал стандартный гитовый filter-branch. За основу я взял следующие статьи:

• Moving Files from one Git Repository to Another, Preserving History
• Splitting a subfolder out into a new repository

В этом посте я хочу немного адаптировать процесс для лучшего восприятия.

На конференции HighLoad++ 2016 руководитель разработки «М-Тех» Вадим Мадисон рассказал о росте от системы, для которой сотня микросервисов казалась огромным числом, до нагруженного проекта, где пара тысяч микросервисов — обыденность.

Тема моего доклада — то, как мы запускали в продакшн микросервисы на достаточно нагруженном проекте. Это некий агрегированный опыт, но поскольку я работаю в компании «M-Tех», то давайте я пару слов расскажу о том, кто мы.

Если коротко, то мы занимаемся видеоотдачей — отдаём видео в реальном времени. Мы являемся видеоплатформой для «НТВ-Плюс» и «Матч ТВ». Это 300 тысяч одновременных пользователей, которые прибегают за 5 минут. Это 300 терабайт контента, который мы отдаем в час. Это такая интересная задача. Как это всё обслужить?

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

Каждый, кто пользуется командной строкой Linux, встречался со списками полезных советов. Каждый знает, что повседневные дела вполне можно выполнять эффективнее, да только вот одно лишь это знание, не подкреплённое практикой, никому не приносит пользы.

Как выглядят типичные трудовые будни системного администратора, который сидит на Linux? Если абстрагироваться от всего, кроме набираемых на клавиатуре команд, то окажется, что команды эти постоянно повторяются. Всё выходит на уровень автоматизма. И, если даже в работе есть что улучшать, привычка противится новому. Как результат, немало времени уходит на то, чтобы делать так, как привычнее, а не так, как быстрее, и, после небольшого периода привыкания – удобнее. Помнить об этом, сознательно вводить в собственную практику новые полезные мелочи – значит профессионально расти и развиваться, значит – экономить время, которое можно много на что потратить.

Перед вами – небольшой список полезных приёмов работы с командной строкой Linux. С некоторыми из них вы, возможно, уже знакомы, но успели их позабыть. А кое-что вполне может оказаться приятной находкой даже для знатоков. Хочется надеяться, что некоторые из них будут вам полезны и превратятся из «списка» в живые команды, которыми вы будете пользоваться каждый день.

Недавно мы в Voximplant улучшали авторизацию в SDK. Посмотрев на результаты, я несколько опечалился, что вместо простого и понятного токена их стало две штуки: access token и refresh token. Которые мало того что надо регулярно обновлять, так еще документировать и объяснять в обучающих материалах. Помня, что в OAuth два токена нужны в основном из-за разных сервисов, на которых они используются (даже вопрос на stackoverflow есть), а у нас такой сервис один, я несколько офигел и пошел на второй этаж вытрясать души из разработчиков. Ответ получился неожиданным. Его нет на stackoverflow. Зато он есть под катом.

Это третья статья из цикла

И сегодня она попала в поток «Администрирование». Сегодня мы не будем писать модули или настраивать RBAC, а пойдем по пути наименьшего сопротивления и просто захарденим обычный LAMP-сервер при помощи готовой политики, включив необходимые настройки.

Если кто забыл, за аббривиатурой LAMP скрывается Linux, Apache, Mysql, PHP, т.е. это большая часть всех VDS, которые покупают люди для хранения своих личных блогов. Надеюсь, что этот поможет всем им стать немного безопаснее :)

Александр Лебедев выражает всю нетривиальность дизайна REST API. Это — расшифровка доклада Highload++ 2016.

Всем здравствуйте!

Поднимите руку те, кто фронтенд разработчик в этом зале? Кто мобильный разработчик? Кто бэкенд разработчик?

Бэкенд разработчиков большинство в этом зале сейчас, что радостно. Во-вторых, почти все проснулись. Чудесная новость.

Пару слов о себе

Кто я такой? Чем занимаюсь?

Я фронтенд team lead компании «Новые Облачные Технологии». Последние 5 лет я писал веб фронтенд, который работает с REST API и который должен для пользователя работать быстро. Я хочу поделиться опытом о том, какие API должны быть, которые позволяют этого добиться.

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

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