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

Тот способ основывается на использовании метода DOM элемента getComputedStyle. Будучи вызванным у HTMLAnchorElement, он позволяет различать :visited и обычные состояния ссылок на популярные сайты.

Баг давно закрыли и больше им воспользоваться нельзя.

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

Ниже приведен полный исходный код proof-of-concept реализации этого способа. С его помощью можно продемонстрировать, что вы посещаете сайт habrahabr.ru, но ни разу не были на сайте hornet.com.

^{Вавилонская башня, 1563. Питер Брейгель (Старший). Музей истории искусств в Вене}

Компания Google запустила вторую версию Google Art Project. Коллекция многократно расширена. По сравнению с первой версией, количество музеев увеличено с 17 до 151, и теперь на сайте представлены оцифрованные копии более 30 000 работ — картины, скульптуры и произведения архитектуры, исторические и религиозные артефакты. Улучшены интерфейс, появились фильтры для поиска работ, режим слайдшоу и сопроводительные материалы.

Мозилловский Boot to Gecko (B2G) — проект построения полной и достаточной (standalone) операционной системы для открытой Паутины. Его цель — сделать веботехнологии первоочередным выбором для приложений на десктопах и в мобильниках; и мы верим, что B2G сможет заменить собою собственнические, поставляемые единственными поставщиками наборы для разработки приложений. На этом пути мы достигли определённых успехов и хотим ими с вами поделиться!

Проект Boot to Gecko

Начнём с того, что окинем взглядом составные части проекта:

Задачи

Boot to Gecko — мозилловская операционная система для мобильных устройств, основанная на веботехнологиях с открытым исходным кодом. Это среда разработки для аппаратной платформы открытой Паутины, как было показано в феврале 2012 года на Мировом мобильном конгрессе (Mobile World Congress).

Технология

Архитектура Boot to Gecko устраняет необходимость приложений устраиваться поверх особенных, одноплатформенных API. Используя HTML5, разработчики отовсюду могут создавать прямо в Паутине умопотрясающие приложения и средства взаимодействия с пользователями, не обременённые правилами и запретами тех платформ, которые подконтрольны производителям.

Открытые доступные стандарты

Как и во всех проектах Мозиллы, исходный код открыт и доступен, и проект основывается всецело на открытых стандартах. А там, где открытых стандартов ещё нет (управление телефонной связью, SMS, фотовидеокамерою, Bluetooth, USB, NFC), Мозилла взаимодействует с комитетами по стандартизации и с поставщиками, чтобы создавать стандарты. Подробнее об этом читайте, пожалуйста, во блогозаписи «Мозилла и эволюция API мобильной Паутины».

Вот несколько интервью (и в них поразительная смесь языков) — это интервью с разработчиками проекта Boot to Gecko:

14 повседневных применений FFmpeg.

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

Когда я показываю босу, что окончательно пофиксил баг



Когда проджект-менеджер входит в офис

Один из наиболее популярных способов связи мобильного приложения с сервером — отправка push уведомлений пользователю. Если Вы уже сталкивались с реализацией push уведомлений, то для Вас открытия Америки не произойдет, однако, новичкам в данной теме приходиться туго — это связанно с огромной путаницей в информации (от переводчика: действительно довольно много противоречивой, а зачастую и вовсе бесполезной информации). Именно эта путаница стала причиной написания данной статьи для WellWithMe, где я опишу разработку серверной части push уведомлений.

От переводчика

Это перевод статьи Drew Crawford «Why mobile web apps are slow», опубликованной 09 июля 2013. Статья очень интересная, но большая — ошибки возможны — прошу простить и присылать замечания в личку.
Поскольку затронута острая тема, прошу заметить, что переводчик не обязательно разделяет мнение автора статьи!
При переводе текст слегка видоизменялся, поскольку прямой перевод не всегда понятно передает смысл. Для перевода термина «native code» был использован англицизм «нативный код», который понятнее и короче, чем «родной для платформы код». Термин «word processing» переводится как «верстка текста», хотя это немного сужает первоначальный смысл. Термин managed код («управляемый код») не был переведен, так как удачного перевод (на взгляд переводчика) не существует. Под «терминированием» приложения подразумевается его принудительное завершение операционной системой.
Повествование в статье ведется от первого лица: автора статьи.

Недавно передо мной стала задача разработки IPhone и Android приложения. Опыта разработки под IOS у меня ранее не было, да и хотелось написать один раз и запускать на обеих платформах. Соответственно был выбран был выбран Javascript и PhoneGap.

И если с языком я определился относительно быстро, то далее было много вопросов.
Хотелось сделать, что бы приложение максимально повторяло интерфейс IOS7 и было похоже на native по скорости работы. При этом с одной стороны не было желания использовать «монстров», на подобии dojo или jquery mobile. c другой стороны хотелось получить удобную модульную MVC структуру приложения.

В итоге в финал моего личного сравнения вышли:
— Ionic framework: http://ionicframework.com/
— Framework7: http://www.idangero.us/framework7/

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

Итак, опишем наш взгляд на решение проблемы.

Для чего?

Работая с AngularJs вы обязательно задумаетесь о правильной организации кода. Конечно уже существуют отличные примеры решения проблемы. Например можно изучить теоретический пост Брайана Форда или практическое руководство Клиффа Мейерса. Я же поделюсь способом организации кода в приложениях AngularJs с использованием RequireJs.

Данный подход будет полезен, если вы хотите:

• перестать беспокоиться о подключении скриптов в правильном порядке;
• загружать javascript код асинхронно;
• иметь возможность скомпилировать код в один минифицированный JS-файл;

Постараюсь быть неимоверно кратким.

Написано для тех, кто только начинает!

Статей про наследование в JS не счесть:

• Здесь, на Хабре
• google
• yandex

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

У меня в google по запросу "what is the difference between inheritance and legacy" первая ссылка ведёт сюда: ссылка.

Само собой, что статей там не одна.

Там есть такая строчка, дописка: Also, as pointed out in some comments, «inheritance» is generally from the viewpoint of the receiver, while «legacy» is from the viewpoint of the giver: My inheritance was my father's legacy.

Краткая суть, которая не отражает всей глубины, которую я себе уяснил, в том, что:

• legacy — это взгляд со стороны родителя, широкий
• inheritance — это взгляд со стороны потомка, узкий

Поэтому я считаю, что в обычных ООП языках программирования типа Java, C#, С++ и т.п. используется термин inheritance — наследование.

А у нас в JavaScript используется почти то же самое, но немного шире: legacy — наследство.

А т.к. в Русском Языке разницы между этими понятиями почти нет, то отсюда и масса FuckUp'ов с пониманием зачем это нужно.

И, в том числе потому, что от Legacy code мы никуда не денемся.

UPD 2: Выжимка из статьи про legacy code >> Modern interpretations.

… source code inherited from someone else and source code inherited from an older version of the software…

UPD 3: Под катом идёт речь о том, что Inheritance неминуемо влечёт за собой Legacy. Точней наоборот, согласно терминологии носителей языка Legacy — это больше чем Inheritance.

UPD 1: В комментариях подсказывают, что может быть частично речь идёт о Гипотезе Сепира-Уорфа. Спасибо k12th. Так же спасибо lair за конструктивную критику.

Как обещал ранее, я публикую исходный код, демонстрирующий, как построить HTTP-сервер в режиме prefork, используя Web Workers и новый API net.Server.listenFD(). Я надеюсь, что этот код будет хорошим примером того, как легко нагрузить несколько ядер сервера, комбинируя пересылку файловых дескрипторов и Web Workers.

— На женщин всегда производят впечатления крайности. Либо слишком большие, либо слишком маленькие. …
Алекс Экслер, «Ария Князя Игоря, или Наши в Турции»

Предвидя вопросы «когда тираж?» — докладываю. Виртурилка в тиражном виде готова на 99%, осталось сделать сэмплы и проверить живьём. На это неделя-две уйдёт, после чего мы готовы к тиражу. Просто к нам приходит много укоров в том что мы пару публикаций сделали и пропали. Количество тиражных экземпляров увеличили до 5000, ибо предзаказов на 2 тысячи набралось. Предзаказ ещё открыт до конца месяца.

Ну а теперь по теме топика

После наших давних экспериментов с гонками на маленьких машинках (дистанционно, через Инет) решили попробовать погонять на чём-то побольше. Были опробованы разные тележки, гусеничные и колёсные. Но не покидало ощущение что это что-то не то. Это ощущение постепенно привело к мысли что нефиг мелочиться и надо делать машинку в масштабе 1:1

NPM — пакетный менеджер для node.js, аналог GEM в RoR. В статье несколько советов по его использованию.

Установка пакетов

Все знают

# Устанавливает пакет express
npm install express

Какие варианты еще есть?

После двух лет работы над OT (техника разрешения конфликтов при совместном доступе к данным) для Google Wave, Джозефу(Joseph Gentle) пришла в голову идея, что для тех, кто захочет сделать аналогичный продукт, потребуется ни чуть не меньше времени. Чтобы как-то помочь этим людям и поделиться знаниями была написана библиотека ShareJS, представляющая собой реализацию OT на основе NodeJS. Также есть C-реализация.

Invisible.js — библиотека, позволяющая использовать одни и те же модели данных как на клиенте, так и на сервере. На сервере работает поверх express.js на клиент отдается через browserify.

Что есть:

• возможность один раз описать модель (включая типизацию и валидацию) и использовать ее на клиенте и на сервере,
• связь с MongoDb (при записи на сервере — объект пишется сразу в базу, при записи на клиете, используется RESTful API, автоматически созданное на сервере),
• хуки на изменение данных (события бегают туда-сюда через socket.io).

Этот текст является переводом статьи 'Stop Being Cute and Clever' небезызвестного (по крайней мере, в Python-комьюнити) Армина Ронахера.

Последние дни в свободное время я занимался созданием планировщика. Идея была простой: создать некий клон worldtime buddy c использованием AngularJS и некоторых других JavaScript-библиотек.

И знаете что? Это было отнюдь не весело. Я уже давно так сильно не злился, работая над чем-либо, а это что-то значит, потому что обычно я быстро высказываю своё недовольство (прошу прощения у моих фолловеров в Twitter).

Я регулярно использую JavaScript, но мне редко приходилось сталкиваться с кодом других людей. Обычно я привязан только к jQuery, underscore и иногда AngularJS. Однако в этот раз я пошел ва-банк и решил использовать различные сторонние библиотеки.

Для данного проекта я использовал jQuery, без которого уже нельзя обойтись (да и зачем?), и AngularJS с некоторыми UI-компонентами (angular-ui и биндинги к jQuery UI). Для работы с часовыми поясами использовался moment.js.

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

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

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

Angular — зрелый и мощный JavaScript-фреймворк. Он довольно большой и основан на множестве новых концепций, которые необходимо освоить, чтобы работать с ним эффективно. Большинство разработчиков, знакомясь с Angular, сталкиваются с одними и теми же трудностями. Что конкретно делает функция digest? Какие существуют способы создания директив? Чем отличается сервис от провайдера?

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

В этой серии статей я собираюсь воссоздать AngularJS с нуля. Мы сделаем это вместе шаг за шагом, в процессе чего, вы намного глубже поймете внутреннее устройство Angular.

Мы продолжаем писать про проектирование сайтов и разработку интерфейсов. На этот раз выделили сразу 19 принципов построения интерфейсов. Эти принципы мы по крупицам собирали на протяжении последних 3х лет работы из разных книг, статей, исследований и, конечно, собственного опыта разработки интерфейсов.

Создание интерфейсов в проектировании больших сайтов – это самый объемный и один из самых важных этапов. Поэтому я отдельно решил выделить принципы и законы проектирования интерфейсов.

• Принцип KISS. От англ. «keep it short and simple». Интерфейс должен быть простой и понятный, задачи должны решаться минимальным числом действий, все должно быть понятно и очевидно.
• Не заставляйте думать. Нужно избегать сложных действий, которые заставляют пользователей думать.
• Убираем очевидное. Не стоит показывать очевидные элементы интерфейса, нужно сосредоточиться только на действительно необходимых вещах.
• Соотношение сигнал / шум. В каждом интерфейсе есть важные элементы (сигналы) и маловажные или даже бессмысленные для определенной части системы (шум), естественно, нужно концентрироваться на сигналах и избегать шума.
• Проверенное лучше модного. Не стоит цепляться за моду и делать что-то только потому, что так делают другие, лучше отдать предпочтение проверенным элементам интерфейса.