Всем привет!

Меня зовут Женя Заремба. Пару месяцев назад я написал статью о продвижении видео на YouTube. Тогда я получил множество вопросов и в результате решил написать расширенный гайд по аналитике видео.

В этом материале мы поговорим о YouTube Analytics, преимуществах интеграции с Google Analytics, а также о дополнительных данных, которые можно получить, правильно настроив Google Tag Manager.

Ситуация: на Mikrotik на разных портах заведены свои сетки:

• ether2 — 192.168.2.0/24
• ether3 — 192.168.3.0/24
• ether4 — 192.168.4.0/24
• ether5 — 192.168.5.0/24
• wlan0 — 192.168.10.0/24

В этих сетях Mikrotik (модель RB751G-2HnD) раздаёт настройки по DHCP.

Задача: используя Wi-Fi подключить ещё оборудование так, чтобы оно оказалось в сети 192.168.3.0/24.
У меня такая задача возникла из-за того, что на балконе сетевое хранилище (NAS) подключено проводом к роутеру (сам роутер в прихожей). А в гостинной — медиапроигрыватель, который должен показывать фильмы с NAS-устройства. Но в гостинной Ethernet-кабеля нет (т.е. был, но я от него отказался).

Для этого будем использовать второй Mikrotik (модель hAP lite). Оба Mikrotik будут образовывать беспроводной сетевой мост. Для этого на основном Mikrotik создадим ещё один беспроводной интерфейс — виртуальную точку доступа (Virtual AP). В итоге схема должна получиться примерно такой:



Т.е. в этой схеме оборудование NAS и Comp должно находиться в сети 192.168.3.0/24. При этом NAS и Comp физически разнесены и подключены к разным Mikrotik.
ether1 на основном Mikrotik — источник Интернета.

В конце настройки средняя скорость между микротиками за 5 мин составила 220 Мбит/с (по данным утилиты ping test, входящей в RouterOS):

Утро 26 ноября началось для меня с интересной новости — ребята из Perfect Privacy опубликовали информацию об уязвимости Port Fail, которая позволяет раскрывать IP-адрес клиентов VPN-сервисов с функцией проброса портов. Я немного понегодовал из-за того, что ее назвали уязвимостью, т.к. это никакая не уязвимость, а особенность маршрутизации: трафик до IP-адреса VPN-сервера всегда идет напрямую, в обход VPN. Вполне очевидная вещь, подумал я, о которой должен знать любой сетевой администратор. Заметка вменяемая и технически грамотная, придраться можно только к слову vulnerability (уязвимость). Но потом за дело взялись СМИ, и пошло-поехало…



Критическая уязвимость во всех протоколах VPN на всех операционных системах. У-у-у, как страшно!

В новости, опубликованной на Geektimes, изначально имевшей желтый заголовок, было сказано о награде в $5000 за найденную «уязвимость» от Private Internet Access — одного из крупнейших VPN-сервисов. «$5000 за типичную, совершенно очевидную любому сетевику вещь?» — подумал я — «Невероятно!», и высказал свое негодование по этому поводу в комментариях, попутно расписав еще одну, не менее очевидную, особенность маршрутизации, с которой сталкивался любой настраивавший работу двух и более интернет-провайдеров на одном компьютере: ответ на входящий запрос не обязательно уйдет через этого же провайдера и с этим же IP, чего запросившая сторона совсем не ожидает. Если мы представим, что вместо второго провайдера у нас VPN-соединение, то отправив запрос на IP-адрес нашего провайдера, при определенных условиях может получиться так, что ответ на наш запрос мы получим с IP VPN-сервера.

Привет Хабр! В предыдущей статье я рассказал как построить свой облачный хостинг за 5 минут, используя Ansible, Docker и Docker Swarm. В этой части я расскажу о том, как сервисы, запущенные в облаке, находят друг друга, как происходит балансировка нагрузки между ними и обеспечивается их отказоустойчивость.

Это вводная статья, здесь мы сосредоточимся на обзоре инструментов, которые будут решать проблему «обнаружения сервисов» в нашем облаке. В следующей части мы приступим к практике, поэтому я решил дать вам время поближе ознакомиться с ними.

В данной статье я хочу рассказать о некоторых возможностях бесплатной и крайне полезной, но пока еще мало известной надстройки над MS Excel под названием Power Query.

Power Query позволяет забирать данные из самых разных источников (таких как csv, xls, json, текстовых файлов, папок с этими файлами, самых разных баз данных, различных api вроде Facebook opengraph, Google Analytics, Яндекс.Метрика, CallTouch и много чего еще), создавать повторяемые последовательности обработки этих данных и загружать их внутрь таблиц Excel или самого data model.

И вот под катом вы можете найти подробности всего этого великолепия возможностей.

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

К окончанию данного руководства вы получите систему из 3 серверов: балансировщик (lb) и 2 сервера приложений (app1 и app2). Балансировщик будет следить за доступностью серверов и распределять между ними траффик. Серверы приложений будут использовать комбинацию systemd и кластеризации node.js для балансировки траффика между несколькими процессами ноды на сервере. Вы сможете выкатывать код с помощью одной команды со своей машины, и при этом не будет перерывов в обслуживании или необработанных запросов.
Все это можно представить в виде схемы:

Демонстрационное видео о работе стола и о его сборке

Инженер из Мичигана Скотт Рамшлаг [Scott Rumschlag] обнаружил, что ему очень тяжело проводить в сидячем положении весь рабочий день. Ещё недавно он был студентом, и хотя участь студента также в основном сидячая, её получалось разбавлять прогулками пешком и на велосипеде.

Изучив вопрос, Скотт решил самостоятельно спроектировать и сделать стол, который можно будет лёгким движением руки превращать из обычного офисного стола для сидячей работы в стол для работы стоя. Благо, Скотт получил инженерное образование, и ему всегда нравилось работать с деревом.

Несколько месяцев разработки и планирования – и стол готов. Управление столом выглядит довольно простым делом. А для всех тех, кто так же, как он, хочет разнообразить свои рабочие позы, Скотт предлагает приобрести у него чертежи стола всего за $29. На 26 страницах найдутся как изображения всех необходимых деталей с размерами, так и инструкция по сборке. Инструкцию можно скачать в виде PDF сразу после оплаты.

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

То же самое относится к переадресации на сайты для мобильных устройств. Пользователям смартфонов будет удобнее работать не с обычной версией сайта, а с мобильной. Поэтому переадресация, например, с example.com/url1 на m.example.com/url1 оправдана. Однако скрытая переадресация мобильных пользователей на посторонние страницы мешает работе и нарушает рекомендации Google для веб-мастеров.


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

Руководя крупной и регулярно пополняющейся командой программистов, столкнулся с необходимостью быстро разворачивать среду разработки без танцев с бубном в духе «странно, у меня этот же код работает, а у тебя какая версия такой-то библиотеки?»

Получив однажды ссылку от заказчика на Vagrant с вопросом «а почему мы это сих пор это не используем?» принялся осваивать это чудо.

Разрешите представить вам перевод статьи Нолана Лоусона «У нас проблемы с промисами», одной из лучших по теме из тех, что мне доводилось читать.

У нас проблемы с промисами

Дорогие JavaScript разработчики, настал момент признать это — у нас проблемы с промисами.

Нет, не с самими промисами. Их реализация по спецификации A+ превосходна. Основная проблема, которая сама предстала передо мной за годы наблюдений за тем, как многие программисты борются с богатыми на промисы API, заключается в следующем:

— Многие из нас используют промисы без действительного их понимания.

Если вы мне не верите, решите такую задачку:

Вопрос: В чем разница между этими четырьмя вариантами использования промисов?

doSomething().then(function () {
  return doSomethingElse();
});

doSomething().then(function () {
  doSomethingElse();
});

doSomething().then(doSomethingElse());

doSomething().then(doSomethingElse);

Исследование рынка

• Google’s Keywords Tools
• Google Trends
• App Annie – Анализ приложения, Аналитика, Исследование рынка
• Distimo – Анализ приложения, Загрузка оценок и исследования
• Xyologic – Новый подход к поиску мобильных приложений
• Apptrace – Исследование App Store
• AppMonsta – Данные о рынка приложений
• Vision Mobile – Экосистема аналитики фирмы
• MetricsCat –Анализ данных приложения

Маркетеривание/Прототипирование

• POP (Прототипирование на бумаге) – Прототипирование мобильных приложений
• Mockabilly – Приложение для создание макетов для iPhone
• Interface – Продвинутое макетирование и прототипирование под iOS
• Blueprint – Макетирование приложений для iPad и iPhone
• Proptotypes – Меняет статический дизайн в кликабельный прототип для iPhone
• FieldTest – Создание мобильного интерактивного прототипа
• Keynotopia – Keynotopia превращает Keynote и PowerPoint в лучшие инструменты быстрого прототипирования для создания макетов приложений
• Justinmind – Интерактивные каркасы для создания веб- и мобильных приложений
• Fluid UI – Прототипирование под iOS, Android и Windows Приложений
• UI Stencils – Трафареты, эскизы и аксессуары для дизайна пользовательского интерфейса
• App Cooker – Продвинутый генератор макетов для мобильных приложений под iOS
• Proto.io – Мобильное прототипирование
• UXPin – Средства проектирования UX
• AppGyver’s Prototyper – Меняет каркасы в прототипы интерактивных мобильных приложений
• App Mockup Tools – Создание прототипов для iPhone приложений
• WireKit – Комплект каркасов для iPhone приложений
• DevRocket – Панель плагина Photoshop для iOS — разработчиков
• Flinto – Быстрое создание прототипов для iOS
• App Icon Template – Шаблоны иконок для iOS 7 и Android приложений
• PortKit – UX Metaphor Эквивалент для iOS и Android
• iOS 7 Wireframe Kit – «Набор для Иллюстратора, чтобы сделать ваш вайфрейминг днем на пляже»
• SketchMirror –Превью дизайна мобильных приложений со своего девайса
• Invision – Веб и Мобильное прототипирование, а также инструмент для UI прототипирования
• Framer –Инструмент для прототипирования анимаций
• Marvel – Бесплатный инструмент для прототипирования
• Sketch – Профессиональный цифровой дизайн для Mac

Использование литерала объекта, как простого средства для хранения пар ключ-значение давно стало обычным делом в JavaScript. Тем не менее, литерал объекта всё же не является настоящим ассоциативным массивом и по этому, в некоторых ситуациях, его использование может привести к неожиданным результатам. Пока JS не предоставляет нативную реализацию ассоциативных массивов (не во всех браузерах, по крайней мере), существует отличная альтернатива объектам, с нужной функциональностью и без подводных камней.

На момент написания этой статьи в JavaScript еще не существовало официальной модульной системы и все эмулировали модули как могли.

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

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

Дело в том, что раньше не думали, что на JavaScript можно делать огромные проекты, а не просто «пропатчить DOM», поэтому о модулях не думали. Да и вообще не думали о будущем. И тут Внезапно будущее нагрянуло! Все вроде-бы уже есть, а модули в JavaScript, мягко говоря, запаздывают. Поэтому разработчикам приходится крутиться и выдумывать какие-то эмуляторы модульности.

Думаю многие из вас читали прекрасную статью Addy Osmani Writing Modular JavaScript With AMD, CommonJS & ES Harmony, которая стала одной из глав его книги Learning JavaScript Design Patterns в этой статье рассказывается про «современные» JavaScript модули или же читали достаточно старую статью JavaScript Module Pattern: In-Depth 2010 года про «старые» модули.

Я не буду переводить эти статьи и не буду делать из них солянку. В своей статья я хочу рассказать о моем модульном пути. О том как я проделал путь от «старых» модулей к «новым» и что использую сейчас и почему.

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

В последние пару дней мне часто приходится отвечать на вопросы, как я нашёл работу в Германии, поэтому я решил объединить весь свой путь (ещё незаконченный) в единый текст и опубликовать здесь, потому как тема мне кажется интересной и актуальной.

Идея уехать жить куда-нибудь за пределы этой страны была давно, но как-то не сказать, что здесь всё было совсем плохо и невыносимо. Однако вернувшись в октябре из двухнедельной поездки по Европе (Барселона, Брюссель, Амстердам и Прага), желание заметно укрепилось. Плюс уже изрядно достали все эти #крымняш, нефть, рубль и великий Пу.

Вариант с Германией мне подсказала знакомая, которая собирается ехать туда учиться. Погуглил, и действительно — для айтишников (я джава-разработчик) всё очень хорошо. Информации на эту тему в интернете полно, не буду лишний раз дублировать (гуглить по ключевому слову bluecard). Если коротко — достаточно желания работодателя платить вам больше, чем 37 000 евро в год.

Перевод статьи Vincent Driessen: A successful Git branching model

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



В качестве инструмента управления версиями всего исходного кода она использует Git.

Всем привет! Мы как-то задумали сделать легкий вводный курс на тему JavaScript и разработки приложений (он, кстати, скоро будет опубликован): и, пока я собирал материалы к нему, как-то само собой выяснилось, что есть довольно много вещей, которые, так сказать, находятся на переднем крае развития JavaScript. Отсюда родилась идея сделать отдельную обзорную статью в жанре «X трендов на год Y по технологии Z».

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

30 лет ей подражают, копируют, модифицируют — речь идет об IBM Model M, прародительнице дизайна современной клавиатуры.

Изначально для основного освещения одной из комнат, где шёл капитальный ремонт, планировалась обычная люстра. Но недавно мне на глаза попалась суперяркая светодиодная лента Ultra 5000 со светодиодами smd 5630 торговой марки Arlight. Решение было принято быстро, окончательно и бесповоротно — хочу такую ленту в качестве основного света в комнате.

Статья “Как обсуждать деньги с руководством или почему иногда останавливаются карьеры?” неожиданно набрала +165 и под 100 тысяч просмотров, и мы решили продолжить переговорно-зарплатную тематику.

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

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

Дмитрий Коткин “Переговоры о зарплате. Практические рекомендации.”