В этой заметке я расскажу как использовать GrowlNotify, Launchd и AppleScript для периодического вывода всплывающих сообщений (на примере классических латинских выражений). Заметка рассчитана на новичков, профессионалы вряд ли найдут для себя что-то новое.

Для всех вышеупомянутых инструментов дан краткий обзор, чтобы вы могли с минимальными усилиями сделать именно то, что вам нужно — напоминания о событиях, новых сообщениях из социальных сетей, мониторинг и диагностика сетевых сервисов и т.п. Либо можно просто сделать все так, как я описал, и через какое-то время похвастаться друзьям своим знанием латинских фраз. Scientia potentia est.

Все менеджеры пакетов в Unix имеют определенные недостатки и большинство Linux-дистрибутивов пытаются по-разному эти недостатки обойти. В этом посте я расскажу про Homebrew — новый менеджер пакетов, нацеленный на простоту использования.

До Homebrew было несколько различных попыток создать эффективные пакетные менеджеры для OS X. Две наиболее популярные вылились в итоге в Fink и Macports, но у каждой из них все равно есть свои острые углы. В частности, в обоих создание своих пакетов или портов является черезчур сложным.

В Homebrew создавать новые пакеты и работать с ними проще пареной репы. Давайте посмотрим.

У JS есть несколько концепций, связанных с областью видимости (scope), которые не всегда ясны начинающим разработчикам (и иногда даже опытным). Эта статья посвящена тем, кто стремится погрузиться в пучину областей видимости JS, услышав такие слова, как область видимости, замыкание, “this”, область имён, область видимости функции, глобальные переменные, лексическая область видимости, приватные и публичные области… Надеюсь, по прочтению материала вы сможете ответить на следующие вопросы:

— что такое область видимости?
— что есть глобальная/локальная ОВ?
— что есть пространство имён и чем оно отличается от ОВ?
— что обозначает ключевое слово this, и как оно относится с ОВ?
— что такое функциональная и лексическая ОВ?
— что такое замыкание?
— как мне всё это понять и сотворить?

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

• Выбрать домен и быстро проверить его занятость.
  Любой регистратор доменных имен предлагает вам форму, в которую вы вводите желаемое слово, просит ее отправить, подождать несколько секунд, узнать свободно ли имя. Затем повторить. Если вы в высококонкурентной нише, где все словарные имена заняты, то провести за этим увлекательным занятием можно несколько часов. Эту проблему для меня несколько лет подряд решал domainr, который проверяет домены как только ты вводишь их названия.
  
  
• Отложить несколько удачных доменов, чтобы после выбрать лучший.
  Это невероятно, но практически ни один сервис, кроме namemesh, не дает добавить домены в избранное. К сожалению, он просит зарегистрироваться, как мы все это любим. На сайтах регистраторов задача решается при помощи корзины. Сначала добавляем все в заказ, затем выкидываем лишнее. Долго, неудобно, нет вариантов перед глазами.
  
  
• Купить домен там, где его продают и где он дешевле.
  Проблема аккредитации регистраторов касается в первую очередь newTLD-доменов (.bike, .restaurant, .tools и прочие). У вашего любимого регистратора легко может быть .travel, но отсуствовать .work. Узнать, кто может зарегистрировать для вас уже привычный домен .io нетривиальная задача, не говоря уже о том, чтобы найти место, где сделать это дешевле.
  
  Задача регистратора в том, чтобы внести запись о домене в единую базу данных и предоставить набор сервисных услуг, связанных с адресом (DNS, SSL и прочие). Текущие реалии таковы, что почти все регистраторы предлагают одинаковые услуги, но берут за это совершенно разные деньги. И если разница в 300 рублей на покупку .ru-домена у разных регистраторов не особенно принципиальна, то зарегистрировать десяток typo-доменов в зоне .net может стоить от 3 000 до 13 000 рублей в зависимости от регистратора ($8.99 / 650 р / $34.99).

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

Многие из нас занимаются изучением английского языка, потому что в сфере ИТ большинство документации, форумов и просто полезной информации изложено на универсальном языке – английском. И каждый находит для себя свой подход к обучению: кто-то идет к своей цели постепенно, планомерно, кто-то более экспрессно и выборочно. В самом деле, в Интернете вы найдете более 9000 методик, о том, как эффективно и быстро выучить язык самому. В языковой школе вам предложат несколько целевых программ: от «разговорных навыков делового человека» до «целенаправленной сдачи TOEFL». Чего же нового хочу я предложить? Мы поговорим о «фоновом» изучении языка. Цель моего поста – поделиться с вами способами изучения языка, которые я использовал. Постараюсь показать концепцию в целом, который каждый из вас сможет интегрировать в свой способ познания языка.

Это руководство — начальный материал о кросс-DPI и кроссплатформенном дизайне для начинающих и средних дизайнеров, желающих узнать о нем с самого начала или получить больше знаний. Без сложных математических и непонятных диаграмм, только непосредственные объяснения, упорядоченные в небольших разделах, для понимания и применения их непосредственно к вашей дизайнерской работе.

Автор — Sebastien Gabriel.

Я не знаю всего, так что, если по вашему мнению я где то ошибаюсь или вам нужно уточнить что-то, либо у вас есть предложения или вопросы для улучшения данного руководства, отправьте письмо (на англ) на sgabriel.contact@gmail.com. Вы также можете найти на меня Twitter, G+ или Facebook.

Приветствую вас, хаброжители! Сегодня я расскажу вам как сделать интерактивную SVG картограмму при помощи d3js.org, о возможностях этой JavaScript библиотеки в общем, а также придётся немного разобраться в том как и где лучше хранить геоинформацию для веба. В финале мы получим следующее:


Начать сие увлекательное путешествие можно под катом.

В практике системного администрирования довольно часто приходится cталкиваться со сложными ситуациями, в которых не помогают ни инструменты сбора статистики (например, netstat), ни стандартные утилиты на основе протокола ICMP (ping, traceroute и другие). В таких случаях часто используются специализированные диагностические утилиты, дающие возможность «слушать» сетевой трафик и анализировать его на уровне единиц передачи отдельных протоколов. Они называются анализаторами трафика, а на профессиональном жаргоне — снифферами. С их помощью можно, во-первых, локализовывать сетевые проблемы и более точно их диагностировать, а во-вторых — обнаруживать паразитный трафик и выявлять в сети зловредное ПО.

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

3 августа в сабреддите /r/Anarchism некто пользователь PhineasFisher создал тред, в котором сообщил о том, что ему удалось украсть 40 гигабайт различных данных компании Gamma International. Возможно, подобная история могла оказаться не столь громкой, если бы не бизнес, которым занимается эта европейская фирма — создание и продажа программных средств для взлома и скрытой слежки (а иными словами — самой настоящей малвари), заказчиками которых обычно выступали государственные структуры. Через несколько дней после первого сообщения взломщик выложил длинный рассказ о том, как ему удалось проникнуть на сервера Gamma International и что удалось там найти.

Пост содержит перевод статьи «Error Handling in Node.js», которую подготовили сотрудники компании Joyent. Статья была опубликована 28 марта 2014 года на сайте компании. Dave Pacheco поясняет, что статья призвана устранить неурядицу среди разработчиков, касаемо лучших практик работы с ошибками в Node.js, а так же ответить на вопросы, которые часто возникают у начинающих разработчиков.

На прошлой неделе мы отметили одну круглую дату — в базе данных Likeastore скопилось, ни много, ни мало — один миллион пользовательских «лайков».

Мы используем JavaScript, все текущие сервисы написаны на JavaScript/Node.js. В общем и целом, я не жалею о использовании Node.js в нашем проекте, он отлично зарекомендовал себя как лучшее средство реализации HTTP API. Но для сбора «лайков», это должен быть daemon, который работает постоянно. Наверно, не самая типичная задача для Node.js — про специфику реализации и некоторые подводные камни, читаем далее.

Я постоянно слышу людей, ноющих об асинхронных коллбэках в JavaScript. Держать в голове порядок исполнения в этом языке немного трудно (это тот случай, который называют «Callback Hell» или «The Pyramid of Doom»), если до этого ты имел дело с синхронным программированием. Моим обычным ответом было «тебе придется как-то с этим обходиться». В конце концов, ожидаем ли мы, что все языки программирования будут выглядеть и ощущаться одинаково? Конечно нет.

Все поменял недавний обзор черновика ECMAScript 6, в котором описываются генераторы — возможность языка, которая целиком изменит наш способ написания и серверного, и клиентского JavaScript. С помощью генераторов мы можем превратить вложенные коллбэки в похожий на синхронный код без блокирования нашей единственной event loop.
Например, этот код:

    setTimeout(function(){
        _get("/something.ajax?greeting", function(err, greeting) {
            if (err) { console.log(err); throw err; }
            _get("/else.ajax?who&greeting="+greeting, function(err, who) {
                if (err) { console.log(err); throw err; }
                console.log(greeting+" "+who);
            });
        });
    }, 1000);

может быть написан так:

    sync(function* (resume) {
        try (e) {
            yield setTimeout(resume, 1000);
            var greeting = yield _get('/something.ajax?greeting', resume)
            var who = yield _get('/else.ajax?who&greeting=' + greeting, resume)
            console.log(greeting + ' ' + who)
        }
        catch (e) {
            console.log(e);
            throw e;  
        } 
    });

Интересно, не правда ли? Централизованная обработка исключений и понятный порядок исполнения.

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

Группировка с использованием элемента <g>

Элемент <g> используется для логической группировки набора связанных графических элементов. Это можно сравнить с группировкой объектов в графических редакторах.

Элемент <g> объединяет в группу все свое содержимое. Как правило, ему задается идентификатор, по которому будет производиться обращение в дальнейшем. Любые стили, применяемые к элементу <g>, будут также применены ко всем его потомкам. Это позволяет задавать стили и преобразования, а также добавлять интерактивность и анимацию сразу целой группе объектов.

В качестве примера будем использовать нарисованную в SVG птичку. Она состоит из нескольких отдельных фигур, описываемых кругами и путями. [По невыясненным причинам автором описаны круги путями вместо использования circle, хоть и было обещано использовать круги. Не спрашивайте почему. Я это исправил. Не спрашивайте зачем. — Пер.]

… а именно как писать LL парсеры для не очень сложных структур при помощи конструирования сложного парсера из более простых. Изредка возникает необходимость распарсить что то несложное, скажем некую XML-подобную структуру или какой нибудь data URL, и тогда обычно возникает либо простыня хитрого трудно читаемого кода либо зависимость от какой то ещё более сложной и хитрой библиотеки для парсинга. Здесь я собираюсь совместить несколько известных идей (какие то из них попадались на Хабре) и показать как можно просто и лаконично написать довольно сложные парсеры уложившись при этом в совсем немного строчек кода. Для примера я буду писать парсер XML-подобной структуры. И да, я не буду вставлять сюда картинку для привлечения внимания. В статье вообще картинок нет, поэтому читать будет трудно.

Последняя часть по работе с сайтом в Скетче.

Abstract: Изоляция приложения на уровне сети использованием network namespaces Линукса. Организация SSH-туннелей.

Традиционно, большая часть статьи будет посвящена теории, а скучные скрипты — в конце статьи. В качестве субъекта для экспериментов будет использоваться Steam, хотя написанное применимо к любому приложению, включая веб-браузеры.

Вместо вступления. Я просто покажу эту картинку:

147%… Что-то мне это напоминает. Впрочем, хабр не для политики.

Цена на игры в Стиме зависит от региона. Регион — от IP'шника. Есть желание иметь цены в рублях, а не в евро.

Для этого мы используем VPN через SSH с использованием tun-устройств, плюс network namespaces для изоляции приложения от всех остальных сетевых устройств.

Network namespaces

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

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

Если у нас есть несколько интерфейсов (один из которых относится к VPN), то нет штатных методов сказать стиму, что надо использовать его, а не eth0/wlan0. Точнее, мы можем «завернуть» весь трафик в VPN, но это не всегда желательно. Как минимум — рост latency и снижение скорости (даже если VPN ведёт на супербыстрый сервер, увеличение latency, оверхед от туннеля и фиксированная ширина локального канала ставят TCP в положение, когда приходится резать скорость). Как максимум — одно дело «покупать через русский VPN», другое дело — пускать туда весь трафик. Меня совсем не прельщает использование VPN для получения защиты роскомнадзором от оппозиции и вольнодумства.

В этих условиях возникает большое желание оставить один на один конкретное приложение и заданный сетевой интерфейс. Один. Сконфигурированный для нужд только этого приложения.

Для решения этой задачи в Linux, уже довольно давно (аж с 2007 года) существует технология, называемая network namespaces, то есть пространства имён для сетей. Суть технологии: над сетевыми интерфейсами создаётся подобие «каталогов», в каждом каталоге может быть несколько сетевых интерфейсов и приложений. Приложение, оказавшееся в заданном сетевом пространстве имён, может использовать (и видит) только те сетевые интерфейсы, которые отнесены к этому пространству.

Картинка ниже поясняет происходящее:

С тех пор как Гугл выпустил в свет инструмент для автоматизации тестирования monkeyrunner прошло немало времени, а улучшений в нем не видно. Тем не менее, для задачи регулярной проверки веб-страниц на корректность верстки лучшего инструмента не нашлось. Те, кому просто нужен готовый скрипт для сравнения скриншотов страниц на андроиде с поддержкой прокрутки, могут сразу скачать его по ссылке. Под катом же будет рассказано, какие проблемы таит манкейраннер, и как их преодолевать.

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

За эталон, к которому я стремился при разработке, был взят проигрыватель http://www.yabla.com (не буду скрывать, изначально планировалось склонировать ресурс целиком, но проект не завёлся). Этот проигрыватель обладает следующими особенностями:

1. навигация по таймлайну осуществляется не с точностью до секунды, а с точностью до предложения. Человеку, изучающему язык по видеороликам, часто приходится проматывать видео назад, чтобы несколько раз переслушать неразборчивую фразу и гораздо удобнее одним кликом переместиться к началу фразы, а не искать её начало несколькими кликами.
2. Каждая фраза может быть зациклена, чтобы прослушать её многократно.
3. Разбивка таймлайна на фразы не требует от редактора какой-то особой подготовки: данные о таймингах выбираются из стандартного srt-файла с титрами.
4. Титры на всех доступных языках выводятся под видеороликом (при желании могут быть скрыты). Эта особенность позволяет, например, показывать пользователю титры на языке оригинала видео и на родном языке пользователя. Клик по слову в титрах ставит видео на паузу и показывает пользователю перевод слова, по которому сделан щелчок.
5. Таймер показывает не только время от начала видеоролика, но также номер фразы и общее число фраз в ролике.
6. Скорость проигрывания ролика может быть замедлена или ускорена.
7. Переход между фразами возможен не только кликом по таймлайну, но и при помощи хоткеев Ctrl + стрелки влево/вправо. Другие горячие клавиши: пробел — зациклить фразу/снять зацикливание, Ctrl + стрелки вверх/вниз — изменение скорости ролика.

1. Фильтры отображения

Анализаторы трафика являются полезным и эффективным инструментом в жизни администратора сети, они позволяют «увидеть» то что на самом деле передается в сети, чем упрощают диагностику разнообразных проблем или же изучение принципов работы тех или иных протоколов и технологий.
Однако в сети зачастую передается достаточно много разнообразных блоков данных, и если заставить вывести на экран все, что проходит через сетевой интерфейс, выделить то, что действительно необходимо, бывает проблематично.
Для решения этой проблемы в анализаторах трафика реализованы фильтры, которые разделены на два типа: фильтры захвата и фильтры отображения. В прошлый раз мы рассматривали фильтры захвата. Сегодня пойдет речь о втором типе фильтров – о фильтрах отображения.
Фильтры отображения, это разновидность фильтров, позволяющая отобразить только те кадры, которые необходимы в данный момент (принадлежат определенному протоколу и/или узлу), временно скрыв все остальные.
Правила написания фильтров отображения отличаются от правил написания фильтров захвата. Отличая не такие уж большие, но как правило достаточные для того что бы правило фильтра захвата без каких-либо изменений не работало будучи примененным как фильтр отображения.

1. Фильтры захвата

Анализаторы трафика являются полезным и эффективным инструментом в жизни администратора сети, они позволяют «увидеть» то что на самом деле передается в сети, чем упрощают диагностику разнообразных проблем или же изучение принципов работы тех или иных протоколов и технологий.
Однако в сети зачастую передается достаточно много разнообразных блоков данных, и если заставить вывести на экран все, что проходит через сетевой интерфейс, выделить то, что действительно необходимо, бывает проблематично.
Для решения этой проблемы в анализаторах трафика реализованы фильтры, которые разделены на два типа: фильтры захвата и фильтры отображения. Сегодня пойдет речь о первом типе фильтров – о фильтрах захвата.
Фильтры захвата, это разновидность фильтров, позволяющая ограничить захват кадров только теми, которые необходимы для анализа, уменьшив, таким образом, нагрузку на вычислительные ресурсы компьютера, а также упростив процесс анализа трафика.