Через WebRTC можно получить список всех локальных (находящихся за NAT) интерфейсов в системе.

Пример кода на JavaScript jsfiddle.net/GZurr

Работает только в браузерах поддерживающих WebRTC, на текущий момент это Firefox и Chrome.

Это можно использовать для получения более точного фингерпринта браузера или, например, разоблачения персонажей, сидящих за VPN, чтобы ВЫЧИСЛИТЬ ПО АЙПИ И НАБИТЬ Е**ЛЬНИК

Для удобства использования я изготовил js-сниффер, который можно вставить на страницу и удобно просматривать результат его работы: zhovner.com/jsdetector

Достаточно вставить на страницу код:

<script src="//zhovner.com/jsdetector.js?name=test"></script>

Где test нужно заменить на слово, по которому будет доступен результат работы сниффера: zhovner.com/jsdetector/test

Каждый, кто посвятил себя работе с компьютерами, хоть раз, но сталкивался с распространёнными высказываниями вроде: «Помоги мне сделать %work%, ты ведь всё равно без дела за компом сидишь». Особенно часто в эту ситуацию попадаёшь, когда работаешь непосредственно в окружении коллег проделывающих ручную работу. Для этих людей ты зачастую представляешься воплощением безделия и главным пользователем youtube.
Сейчас я покажу вам один из приёмов, как превратиться в глазах сотрудников из лодыря в волшебника.

В прошлый раз мы написали довольно популярную статью: «Серьезное проектирование серьезного магазина. Часть 1. Исследования», эта статья её логическое продолжение. В этой статье и в последующих мы опишем почти 60 функциональных модулей топовых интернет-магазинов мира, а также подробно разберем интерфейс многих страниц.

Лично меня жизнь убедила, что люди это капитал. Особенно в нашей отрасли все зависит от людей. Если кто-то сомневается в этом, то очень рекомендую книгу шведов Кьелла А. Нордстрема, Йонаса Риддерстрале, «Бизнес в стиле фанк. Капитал пляшет под дудку таланта». Книга не новая, но, имхо, очень доходчиво разъясняет, почему Маркс, Ленин и Мао Дзэдун были правы в современном мире это именно так.

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

Доброго времени суток, уважаемые хабравчане. Недавно Hugo Giraudel, он же CSS гоблин, SASS хакер и Margin псих опубликовал в своем блоге очень интересную CSS задачку на смышленость.



Сможете заверстать подобное учитывая следующие правила?

• Круг в центре должен быть прозрачным, чтобы был виден background
• Расстояние между левыми и правыми блоками, как между верхними и нижними должно быть одинаковое
• При наличии потомков в блоке, содержимое должно отображаться
• DOM должен выглядеть следующим образом: ul > li > section > header + footer
• Нельзя использовать JavaScript и изображения
• Дополню еще от себя: нельзя использовать CSS Shape и Clip Path

Чтобы не было очень лень — каркас уже есть.

Сделали?

По причине «интересно», на досуге, собрал простой upnp/dlna сервер. Написанных на javascript найти не удалось, а идея кажется интересной: один исходный код для всех платформ (спасибо node-webkit), javascript со всеми его достоинствами и недостатками, а также простота сборки. Можно легко собрать проект под все платформы в одной из них. Для этого написал скрипт на питоне, который все сделает сам, даже скачает необходимые файлы node-webkit. Хотелось снизить кол-во телодвижений необходимых для тех, кто захочет внести свою лепту в проект.

Скачать можно здесь, спасибо github за то, что вернули возможность хранить файлы. Умеют сделать людям хорошо. Еще немного текста можно найти под катом.

Описание задачи

Часто у разработчиков веб приложений, а также разработчиков для мобильных платформ возникает задача отсылать нотификации о завершении некоторого события. Например: уведомить пользователя о запланированной встрече, звонке, определенной записи в расписании (todo листы) или просто создать напоминание о любом другом действии в будущем.

Привет, уважаемое Хабра сообщество. В один из прекрасных летних дней, позвонил мне мой товарищ, и сказал, что у него есть для меня очень интересная задача. Я люблю интересные задачи. Приехав на следующий день в офис, мы обсудили задачу. Задача, в двух словах, поставлена была следующая: отобразить на браузерном канвасе иерархию ~ 30000 пользователей с зависимостью между ними, плюс должна присутствовать некая анимация, которая в контексте данного поста не существенна, может в будущих, если на то будет время и Ваше одобрение.

Мы ударили по рукам, я сказал, что мне нужно провести «изыскания», так как сфера (JS + Canvas), была для меня была нова, и выяснить насколько развитие браузерных технологий соответствует реалиями поставленной задачи.

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

С тех пор, много воды утекло, появилась версия сигмы 1.0.0, я обрел новый багаж знаний в сфере JS + Canvas и веба в целом. Для тех, кого я заинтриговал, прошу под кат, где будет дан краткий обзор библиотеки — sigmajs.

Привет, Хабра!

Я люблю игры на JavaScript и стараюсь сделать их код пуленепробиваемыми для портирования на все платформы. Полгода назад я уже писал о сборке Android приложений и сегодня хотел бы раскрыть тему более подробно.

Сразу предупрежу, что мне пришлось отказаться от PhoneGap, т.к. опыт использования его в двух проектах меня огорчил. Он отлично справляется с «Hello World» приложениями, но при конвейерной сборке всего подряд всплывают нюансы.

Почему PhoneGap не пошел:
1. Он изначально пустой. Постоянно приходится подключать все новые и новые модули.
2. Многие модули написаны криво. Они либо берут много лишнего, либо ведут себя неожиданно. Например, из двух модулей под Android для отправки SMS, один не работал, второй — отправлял true при любых условиях.
3. Не решены элементарные вещи, вроде получения EMEI телефона. Нужно постоянно допиливать.

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

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

Доброго времени суток, уважаемые хабравчане. За последнее время я увидел несколько интересных и полезных инструментов/библиотек/событий, которыми хочу поделиться с Хабром.

BrowserSync

Я считаю это лучшим Live Reload инструментом. BrowserSync — это: конечно же перезагрузка страницы после изменения исходных файлов в том числе и серверных (PHP, ASP, Rails и др); синхронизация с десктопами, планшетами и смартфонами; синхронизирует между браузерами скроллинг, данные в формах и множество других действий; существует как Grunt и Gulp плагин; доступен на Windows, Linux, MacOS.

npm install -g browser-sync

// Using a an IP based host
browser-sync --proxy "192.167.3.2:8001" --files "app/css/*.css"

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

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

Ужасно не люблю выражение «заставить себя». По моему убеждению, нельзя заставить себя — с собой можно только договориться. Ну, или обмануть — но это не лучший выход.
Итак, как договориться с собой сделать что-то, что совершенно явно не хочется делать? И настолько же явно необходимо.
Некоторое время назад я прочёл в блоге психолога Хайди Халворсон о трёх простых причинах, которые мешают нам что-то делать, и таких же (ну, почти) простых решениях этих проблем. И поскольку время показало, что решения (по крайней мере, мне) подходят — спешу поделиться ими.

Итак, почему же дедлайн близится, а решения всё нет?

О чем это все

Это будет короткий пост. Сначала личная история, а потом как это применить на практике к управлению сотрудниками.
Чисто опыт, никаких теорий.

Во-первых, часто говорят о работе на результате. О людях, ориентированных на процесс или на результат. Соотношение, как говорят, 95% к пяти. Рекомендую всем менеджерам проектов для начала великолепное видео Сергея Котырева в тему. Кстати, горячо рекомендую и другие видео посмотреть — Сергей достиг успеха на непростом рынке и знает, о чем говорит.



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

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

Для понимая того, почему такие люди появляются в организации, рассмотрим модель развития специалиста, построенную на параметрах «навык / мотивация». Основу для неё я взял из модели ситуационного лидерства и немного развил, исходя из практических наблюдений. Эта модель нужна, чтобы понять, на каком этапе «жизненного цикла» могут находиться на нашем проекте, и как это влияет на их мотивацию.

Этап 1 – мало опыта, много энтузиазма (низкий навык, высокая мотивация). Это может быть молодой специалист, получивший первую работу; человек, решивший попробовать себя в новой профессии или профессионал, которого выдвинули на руководящую должность. В общем, любой из вариантов, когда человек только что пришел на новое место, очень хочет добиться успеха, но еще не понимает как это сделать.

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

Всем привет! Встретил статью о том, как на сайте meteor.com обеспечена работа для высоких нагрузок. Звучит это довольно интересно. (пер.)

Во-первых, зайдите на meteor.com и посмотрите, как это работает.

Мы все знаем, что meteor.com сделан на Meteor. Вы можете заметить, что загружается он очень быстро. Также, у него нет процесса загрузки — после того, как HTML построен, страница сразу отображается на экране.

Но как это возможно? Обычно, это занимает какое-то время — подключение к серверу, получение данных и отображение информации на экране. Может, Meteor использует какую-то магию с Galaxy?

DerbyJs — реактивный фулстек javascript-фреймворк. О нем неоднократно писали на хабре — материалы по Derby. Буквально пару дней назад в репозитории Derby произошла смена основной ветки. Теперь версия 0.5 отошла на задний план, 0.6 — основная.

Не в традициях команды разработчиков заниматься пиаром — изменения произошли тихо и незаметно. А что же поменялось?

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

Некоторое время назад я, в поисках новых инструментов для реализации очередного «домашнего» проекта, наткнулся на Kraken.js — Open Source проект от PayPal. Kraken.js представляет из себя очередной Node.js-фреймворк, основанный на express. Поискав на Хабре, я не обнаружил, ровным счетом, ничего. Встретил только одно упоминание в виде ссылки на главный сайт здесь.

Чем же он меня привлек, и чем он отличается от известных Derby.js, Meteor.js, Sails.js, и др.?

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

Итак, задача залить Kraken.js-приложение на сервис Heroku, заставить его там работать, и, на сладкое, прикрутить Sockjs.